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Abstract 


The VIM computer system, an experimental project under development in the Computation 
Structures Group at MIT, is intended to examine the efficient implementation of functional 
languages using the principles of data flow computation. In this thesis, we examine how to 
incorporate backup and recovery mechanisms into this system to guarantee that no online 
information is lost because of hardware malfunction. Our solution, which takes advantage of VIM’s 
powerful applicative base language and its uniform treatment of data and files, integrates the 
operation of the backup and recovery system within the interpreter itself, resulting in a system that 
can ensure a high degree of data security without excessive performance degradation. Unlike 
schemes found in other systems to guarantee data security, operation of the backup facility requires 

no user intervention. 


To present our algorithms rigorously, we first develop a formal operational model of system 
behaviour. This set-theoretic model views VIM as a state transition system with the interpreter 
serving as a state transition function. The specification language is a superset of the applicative 
language, VIMVAL. We enhance this model to include a concept of system failure and augment to 
the basic components in the system a backup state with the base language instructions now — 
operating on both the VIM as well as the backup state. A formal proof demonstrating the 
correctness of our algorithms is also given. Issues concerning the implementation of these 
algorithms are also addressed in the thesis. 
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2 . GOALS OF THE THESIS $11 


found in our system provides a framework on which a highly secure system can be designed. 
Unlike its more conventional counterparts, the backup and recovery utilities we present are 
simple and efficient and do not require any ,wser- guidance to perform their task. We model the 
presence of failures and the actions undertaken by the backup and recovery mechanisms by 
defining a formal operational semantics of system behaviour. This formal model is used to give a 
precise description of the behaviour of the backup and recovery system. We demonstrate, using 
this formal model, that the backup algorithms developed properly records the relevant portions 
of the system state and that the recovery system does correctly restore the Proper system state as 
well, 


1.2 Motivation 


The problem of guaranteeing data security is certainly not a new one. Virtually every 
major computer system developed includes some type of protection mechanism to safeguard ‘the 
_ information entrusted to it. It is, therefore, natural for the reader to.question why the'study of 
_ data security for the VIM system is.a problem worthy. of investigation: There are two main 
reasons why we have not chesen to.simply. use backup.and recovety algorithms developed for 
other systems for VIM. First, and foremost, backup.:and:irécovery systems in conventional 
_ systems. are not able to provide full-.data security: without becoming ‘éxcessively: complex: ahd 
inefficient. In general, the implementations. of these utilities are-not able to: provide full data 
security without incurring significant reduction in system-pefformanoe: . In addition to this major 
drawback, these schemes are based on a computational model which is much different from that 
found in VIM. The implementation strategy that we present in this desis 'guararitec¢ fall data 
security and exploits the novel features of VIM in doing sa,. It isaignifxantly.different from other 
data security schemes proposed for both sequential and. parallel: systems: ‘Some of the more 
interesting aspects.of VIM pertinent to-the issue of data security are cited below: 

_oVIM mpee e etee ae architecture. — 


In a data flow computer system, all instructions in, the program. are viewed. as potentially 
executable, with the only constraint being that they must have received all necessary operands 
and control signals. This execution model allows for a great, deal of concurrency to be realjzed. 
“Thus, our data security mechanism must be designed to be used ina highly concurrent 


en viron ment. 
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eViM interprets an applicative base language, namely, the: language-of dynamic data 
flow graphs. 


A dynamic data flow graph is a directed: acyclic graph where nodes represent instructions and arcs 
define data dependencies between these instructions: A®graplt is dynamic if the execution of a 
function activation is explicitly initiated by some apply operator. In our system, each function 
activation has its own graph:created by the epply instruction: ‘The-base ‘language instruction set is 
very powerful, containing instructions for function application and ret#im, structure creation and 
manipulation as well as instructions to handle storage management, We can take advantage of 
this feature i in the design of our data security mechanism by. enhancing the semantics of these 
instructions to support the backup and recovery procedures. 


eThere is no distinction between files and data in: VIM... 


Unlike conventional systems, the units of storage allocation in VIM are the information units on 
which the primitive operations of Vim operate Ze. fiistriictions, scalar Values, arrays, and records. 

© This feature wilt allow us to design backup: algorithinis’ thac’¢art ‘be fly Ophlzai of how 
‘information is being created and manipulated in the'systemn. ee, 


eThe unit of transfer’ between disk and main ) memory is is a small fixed-size unit of 
information calfed:a chunk. 


The small unit of information transfer will allow extensive concurrency of operation to be 

- achieved by exploiting the data driven execution model t6 support ‘ew high tevet’of information 

traffic between disk and main memory. The use“of ofruliké aé‘the ‘unit of transfer poses 

. interesting. problems for the backup system’ when information teéds to’ be vopied from’: memory 
ms nls Maen Ronee ee We discuss this issuetiter ia the thesis, 


1.3 Background 
While hardware is generally reliable for the most part: catastrophes do indeed occur and it 
is necessary that the computer system designer be sensitive to this Agality, . Ideally, we would like 
“to provide a guarantee to the users of our system that all accessible data will survive the effects of 
any hardware malfunction. The approach that is adopjed,. howeves,. will naturally be strongly 
influenced by effi iciency constraints. In Most conventional computer s systenis that do not provide 
extra hardware support to achieve this aim, the cost of. realizing full data. security, usually involves 
too much overhead and reduced performance to be a realistic goal. In these systems, users are 
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forewarned that some of the information they have-entrusted:té the’ system may not survive a 
hardware failure. Consequently, these users must take explicit action to preserve data they deem 
_ important by periodically-"backing up” their information-onto. a:more reliable storage medium. 
Information which is not transferred onto backup stere is:lost-efter.a crash; It is usually not 
possible in most systems to recover this: lost data by reexecusing the computations which initially 
produced it since there is ao mechanisar to monitor the creation andanodification of information 
occurring in the system. 


We shall say that the information held by a computer system is Sully, secure from loss or 
corruption if the system contains mechanisms which ensure the preservation of all data despite 
the presence of unreliable underlying hardware. ‘components, These ‘mechanisms may be 
incorporated as backup and recovery software utitities dr ‘my take the form of replicated storage 
elements or may. be. implemented. as some combination of both. The degree, of data security 
provided by a ‘computer. system js one measure. of its refiabilicy... If a system is reliable, users of 
the system can confidently store and agcess data whenever desined.. Note that: data security, does 
not necessarily imply reliability since a secure. computer system need.not. mask failures to the 
external world. A system which does provide full | data security, however, guarantees i its users 


VF 


that no failure i in the system will cause any accessible informacion 0! be lost-even: though users 
may He Even hom aenne it sad a time if a ane = place, © 


ragye 


The extent.to chick's aSeDS Cah access. si date ‘ised cies siinian deine the avadability of 
_.the system. , In, applications sugh, as, rocket. guidances] for example,:it is-cruciad that no-single 
_ hardware failure makes, the system. unavailable. for, even:.2)sbos period of time. The basic 
approach to masking failyses of hardware from the estereal system-is: best: done at the hardware 
level itself, by incorporating sufficient redundancy into the system [26]. In this thesis, we shall 
not be concemed with availability. Rather, we shall be focusing our attention ott 'the problem of 
. enhancing VIM to provide full data security for.sll online saformation, 


For systems which néed not mask failures, the Standard approach used to guarantee data 

. paar has beet to aa ide pena and  ReCONey software wes ‘er the system. The backup 
‘hardware failure. The recovery ulility is invoked when | a hardware faifisre | occurs and uses he 
information preserved by the backup facility to restore the system 6 a state which existed before 

the failure, The degree of date secutily provided’ by’ ‘the system . “Git ited by the cust of the 
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backup and recovery process. Most current systems ‘have -had to-sacrifice the goal of providing 
. full data seeurity because of the high overhead that would be involved in supporting the ‘backup 
_ and recovery system.. In these systems, the state restored ‘by: the recovery: utility may not be the 


-.- one which existed: immediately prior to the failure. Moreover,-it'is usiially the case that there is 


no means of recovering this desired state: from the one produced by the recovery procedure. 
Thus, information loss is a possibility which users ofthe systent must accept. — 


1.4 Previous Works 

In this section, we: briefly describe some-previous efforts in the design of highly ‘secure 
systems undertaken for both centralized and distributed Systems as. welll as Solutions proposed for 
providing | fault-tolerance for a class of data flow architectures, We Point out some, major 
: deficiencies and assumptions made in these proposals that. make them not suitable for 
he implementation i in our system. 


“£4, 1 Data 1 Security in Centralized Systems 
on conventional single-provessor machines, the simplest and perhaps most direct means of 
° “recording state ‘information ‘for recovery purposes is to establish a checkpoint “describing. all 
" aspects of the system state. ‘The checkpoint state is constructed, by recording the state. of the 
system at some point onto.a reliable storage medium such 85 tape. _ ‘The. most obyious drawback 
of this scheme i is the potentially large amount of data which must be examined - an oftentimes 
~ unnecessary and expensive strategy since most of the objects i in the system | would probably. not 
; have been modified between successive checkpoints, To ameliorate, this problem : somewhat, 
many timesharing systems: ‘perform an activity referred to as incremental dumping to ksep, the 
backup system abreast of any modifications to the file hierarchy between successive checkpoints, 
In the event of a major mishap that necessitates the reconstruction, of the file, hierarchy, the 
system can be reloaded from the last checkpoint and appropriately modified. by, using the current 
incremental dumps to restore the system to a more ‘fecent state, All incremental dumps are 
copied onto magnetic tape. In order that the recovery phase of state restoration may proceed 
faster, incremental dumps are periodically consolidated to remoye outdated copies of files. This 


. consolidation process is known as secondary dumping. 


Using incremental and secondary dumps to record information: «bout the system state is 
the hasic approach used by the Multics operating systent {27} to provide secure service ‘to its 
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users. A modification to the backup and recovery. pratocol-employed by Multics was suggested 
by Benjamin [6] for the Data Network Computer. -Insteadiof using magnetic tape as the medium 
_ to store backup copies, it was ad yocated that the computer system be integrated within a network 
of autonomous systems with.each system being allowed access te the-storage devices of the other 
processing elements. The backup facility maintains.a consistent image.of the file storage at a 
remote site within the network. The motivation for having such a backup system is the greater 
ease in managing the backup system that results when we do not have to deal with sequential 
access tape storage. The problem in using such a system, however, comies‘from ‘the decréase in 
availability that may occur due tothe extra dependency on communication lines etc. 


Perhaps the most serious objection to the solution adopted by Multics i is the cost involved 
in periodically scanning the file hierarchy to find | those files which have been created or updated 
since the last incremental dump. The cost of ‘performing a ; checkpoint i in Multics increases 
linearly as the size of the system increases. To achieve the same degree of data security ina 
heavily used system where files are constantly created, destroyed and updated, as in a lightly 
used one, it is necessary that the backup system be invoked more frequently. This, in turn, 
implies degraded service to the usér community. "The basic. eason why Multics (and other 
| conventional centralized systems) are not able to provide full data security efficiently appears to 
be the inability on the part of the backup system to immediately discern when data has been 
’ created or altered and to Teflect this fact onto the backup i image of the system state, Because the 
mechanism by which data | is created and updated is is far removed from the file le system with which 


‘fesult is a computer system wich cannot guarantee full daia security without i incurring ¢ excessive 
overhead. 


¥.4.2 Distributed Systems 

Unlike single-processor machines or multi-prdcessor machines under centralized control, it 
‘is difficult to ‘perform global checkpoints i in ‘mulli- “processor systems under distributed control 
~ because of the lack of any System wide synchronization capability Hence, although distributed 
“ systems may have the potential of providing ; a more secure computing environment as a result of 
the. redundancy present in their architecture 129]. exploiting such redundancy to achieve this end 
becomes much more difficult... A typical medel chameterizing-a distributed system would be one 


where both the data as well as the code of a process is spread over several physical nodes inthe 
> 
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system. Communication between processes. in such a model is wsually through some form of 
remote procedure call [25] or message. passing mechanism (20, 18,31]: Fathire in these systems 


_ Can cause processes to: deadfock {2}: after the recovery’ phase completes. To avoid deadlock 
problems arising. from the error recovery of a process ‘that is a member of a collection of 


communicating processes, focal distributed systems: or network computers ‘usually have’ the 


ability to set localized checkpoints: for each process: Such cheek points afé tefetred to as recovery 
» points. If a failure of a process is detected, it is necessaty to sot only rollback the failed process 
_ to its most recent. recovery point;‘but to also: reset alt othe¥ processes ‘that’ had’ exchanged 
_. information with the failed process.since the time of tie fast feoovery ‘point in order to: avoid 
.: deadlocks from oocurririg when operation is-continued: If these‘recovéry points are not set 


. properly, it is quite likely:to:have'a.domino effect {2}:whereby all’ provesses ‘{nitiate ‘fecovery 


actions that lead then: to their-earliest recovery point’ ‘Deteimiriiig whet to set recovery points 


- and finding a consistent set of such points is: vintsteniccmcuastadls ‘Often’ iepeaealty 
reduces:the overall concurrency. of the system. 2 


Borg ef ai{7] and Barigazzi{5}: present schemes for onsuting: thé security of data in a 


.. distributed message-based ‘system. ‘The basic: idea in beth: propdsals- ihvolves maintaining an 
. inactive. backup process on:a different processor ‘fir tach ‘acuVe ‘provess‘in the system. ff a 


-> failure of a-primary process occurs, the backup. process takes Over execution. It Borg’s scheme, 
.. Messages exchanged between two processes'are also’ automatically reoorded on backup processes 
. 98 well. In addition, .both the backup and recovery: processes lars ' periodically: synctironized. 


. When a failure occurs on a. primary process, ity backup begind execution in the state that the 
_ failed primary had. at the:jast:synchropaiation point.:' THe backwp can catch up to the state’ the 
_ primary had just before the ieee breeomprig sand On the imeesges which were sent toi 


Barigazzi uses a similar approach i in his system, ‘However, instead of having messages sent 
from the primary to the backup process, an explicit recovery point is is periodically established for 
every primary. Setting a recovery point for a process also fequies establishing recovery points 
for all processes that communicated with this process since the. .Jast secovery. point was: set. 
Recovery i in this scheme involves resetting all processes to their, last ecovery Point. While both 
these schemes provide full data security. they do so at the cost of high overhead i in maintaining 


“up- -to- -date multiple copies of the primary ‘process on disjoint Processors. In addition, both 
proposals assume the transmission of messages to be a relatively Inexpensive. operation, an 


“assumption w hic his certainly arg uable. 
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In addition to general distributed systems, there: has been much interest of late in 
distributed transaction systems for which a high degree of data security is essential. A 
sophisticated approach to handling data security for. transaction based applications can be found 
in the Argus system. The Argus integrated programming language and distributed system being 
developed at MIT [23] is a comprehensive attempt to. provide linguistic support for ensuring data 
security and consistency within a distributed computing:environment. The language provides 
constructs to encapsulate vital data objects which are then guaranteed to survive crashes of the 
host processor with high probability. In addition, a mechanism is provided:to express atomicity 
of process activity, When a hardware failure occurs, each:outstancting atomic action is forced to 
abort. A two phase commit protocol is.used to ensure. that all transactions preserve the 
consistency of the active data. To guarantee data security,. objects: are distinguished as being 
either stable or volatile. Ali stable objects.are written cate stable storage: devices whenever a 
_ transaction completes. The. integrity of stable objects ‘is, therefore, preserved. even though 
crashes of the host node may take place. Volatile data is presumed to be fost upon failure, 


Perhaps the greatest point of contrast between the Angus implementation of data security 
and that which we want to provide in our system is: the sequirement in Argus that the user 
prespecify those objects which are to survive crashes, Our goal is to ensure that measures taken 
to provide data security are transparent to the: ser;.m0 linguistic primitives are. provided to 
"specify the objects he wishes to survive failure and:no explicit constructs are provided to control 
backup operations. While the gap between the programming model and the backup facility is 
-not so severe in Argus as in Multics, the fact that the underlying system is based on an updatable 
memory execution model makes the task of ensuring:a consistent state a complicated one 
involving expensive protgcols such as two-phase commit. and ‘sophisticated. algorithms to 
maintain a correct and up-to-date backup image. Moreover, the application domain for which 
Argus is best suited is a relatively restrictive one and the complexity of the system is probably not 
warranted for most non-transaction based computations. _ 


1.4.3 Fault Tolerant Systems 

| There have becn several proposals put forth for the design of fault-tolerant data flow 
‘computers which attempt to achieve data security (as well as availability) by incorporating low 
level fault masking capability into the system. We outline several of these proposals here to 
present an alternative approach to solving the problem of providing data security for a computer 


system. 


coo tigi tbe RSSTEPEe RS rer a te ees he pe ee E 
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An error recovery system in the context of a fault-tolerant data flow machine based on the 
Dennis-Misunas architecture [9]: was described by Misines: in {24]: Fhe model advocated was 
based on providing triple modular: redundancy:(TMR) for memory-and the functionat ‘units. 
_ Each instruction cell acts as a voter and receives thes fesults foreach operand generating error 
packets if discrepancies are found. “In addition, ‘processor’ failtires ave handled by‘allowing the 
_. network to be reconfigured. The scheme: involves. extensiveoverhedd in téims of increased 

_ packet traffic and extra hardware and. is dependent on the-fole of acknowledgrhent signals to 
allow reconfiguration to take place. A fault-tolerant design for a static lata flow architecture was 
also proposed by Leung [22]. -In his: proposal, a dynaitite-rodwn@iney technique was employed 
whereby redundant units: are used to: detect ‘and — ‘faults, with afflicted ae it 
reexecuted when necessary. ace ce Abhay 3 om 


Hughes [19] suggests that a checkpointing: strategy ‘suitably modified for data flow 
computation may: be:an appropriate mpchanisra for incorperatg érror-recovery in a data flow 
machine, Basically, each cell (or instruction) whidhis:chedkpoittéd ig murked. ‘Whenever the 
backup system initiates a checkpoint, ail! active cells not previously ‘checkpointed ‘are saved: On 
recovery, all active cells that were checkpointed are restored. While simple to implement, 
recovery in ‘this scheme requires the reinitiaization of the “entire ‘state, which is an. often 
unnecessary step. In addition, the memory of the system ‘must be examined at each checkpoint 
to determine which items have not yet been copied; this i is also. 0 quite wi wasteful i in, most instances. 
Finally, this ‘proposal assumes that all information is “realdent in memory whenever the 
. checkpoint process is invoked; by contrast, in-the systent whieh We-envistige: data wilt be ere 
across the memory hierarchy betwean disk and agatha Sigs aed 


All three of the proposals cited here are based on an architectural model rauch different 
. ‘from the dynamic data flow model designed for. VIM. “Moreover, they. require, special 
“architectural enchancements to mask hardware faults, VIM is not intended. for applications 
which have high availability requirements and, thus, there is no need for fault-masking strategies 
to be incorporated into. the system. - Consequentty;- the approaches to: achieving data ‘security 
taken by these schemes will not be directly applicable ia poe Maiirenens we have set 
forth for our system. are 
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1.5 Thesis Outline 


In the next chapter, we present a detailed model.of the VIM Computer System. We 
describe in detail the applicative base language being used and the dynamic data flow execution 
model employed. In addition, a formal: semantics .of system behaviour.is also developed to 
rigorously define its operation. The manner in: whick users communicate with the system and 
the means by which. long-lived objects are defined. are .also presented. To simplify. the 
presentation, we assume.a system supporting only a single.user.. Because of the applicative 
programming model used in VIM; this simplification doesnot invalidate: its applicability to a 
multi-user system. We do not consider non-determinate :comiputation in our model. This 
restriction also simplifies the algorithms. _The complications involved: in incorporating non- 
determinacy into the model is a topic which we discuss in Chapter Six. 


The third chapter in the thesis presents the general-strategy for the backup and recovery 
system. We, define the criteria which. the backup: system ‘will use-in determining what 
information should be recorded onthe backup storage .medium; We also present the 
architectural enhancements necessary to support the: backup and recovery utilities. 


In the fourth chapter, we give a more detailed description of the backup and recovery 
algorithms. The alterations necessary to the interpreter are discussed. We also formalize the role 
of the backup and recovery system in the context of the abstract model given in ‘Chapter Two 
and Present the changes necessary to the base language i instructions to support our algorithms, 


The fifth chapter scactibes low level details in the transfer of information . between the 
backup storage medium and the VIM system. We.discuss-how te: guarantee the. atomicity of 
information transfer so that a consistent image of the system state is maintained on the backup 
storage medium. We also mention. how storage management is handled on the backup store as 
well as Ceeivine, how to minimize the copying of information from system memory onto 
backup n memory. 


The final chapter presents a summary of the thesis and discusses some topics for further 
research. We pay particular attention to the changes which may need to:be made to the backup 
and recovery algorithms if our model of system behaviour is augmented to allow non- 


determinate computation. 
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‘The Vim System. 


The VIM ‘Computer System is an experimental project in | the ‘Computation Structures 
* Group intended for the investigation ofa a novel data flow architecture for the efficient support of 
‘furictional languages. In ‘this chapter, we discuss the design of the system and Present an 
Operational semantics for its applicative. base lariguage. ‘The ‘main Programming language 
‘supported by VIM is VIMVAL, a major ‘extension of the applicative language VAL a. ‘VIMVAL 
programs are translated into the base language data flow graph representation which is then 
_executed by the VIM Jntarpreter, Users communicate with Ving throughia Shell program. The 
_ _ Shell provides a powerful. interface to the system thet aldows:users to build and manipulate VIM 
_ environments - the main fagility for constructing loag-lived stnsctures.:: We ‘discuss each: of these 
_ components, VIMVAL, the, SSC eon a Soeken eam ne see tu. 


2 The Applicative Language, VIMVAL _ 


In., this section, we. present: an: informal overview: of the: VIM high-level applications 
. language, VIMVAL. VIMVAL differs fron: VAL, its predecessor; in: that fuactions are: tweated as 
___ first-class objects, free use-of recursion and mutuab:recursion is allowed, ‘and: polymorphism is 
_ Supported through a Milner-style type inference mechanism. Users can program ina structured 
and hierarchical manner throught dj¢, use of a.moduée construct described delow. 


In addition to various scalar types such as integers, reals, characters and healeans, ViMVAL 
also contains structure types such as arrays and records. Users can express history sensitive 
computation through the use of streams [30]. A stream is a potentially infinite sequence, of 
- homogeneous values which may be of any type (including ‘stream) that allows users to write 
* history’ sensitive codé (sucht as the modeling of a conventional memory cell) within a functional 
"framework. ‘Thére are three operations on streams: ‘first which returns the first element of a 
~ stream. rest which given a stream returns the stream ‘without its firs element, and affix which 
" affixes an element to the head of a stream. We shall discuss the implementation of streams in 


Preater detail in then next section. . 


Beksues fanguicns are treatcd as first-class objects, they~may be: passed as arguments to 
other functions, returned as the result of a function activation: and: may be built. into data 
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structures e.g., array[Function]. The body of a function is an expression whose type is the result 
type of the function. The form of an expression may contain conditional expressions, function 
invocations, tagcase expressions. whieh allow one of a series of expressions to be chosen based on 
the value of a bees and let vidoes which are viewed as SORTS, for lambda abstractions. 
considered @ as oAly identifiers for a value. Once an 1 identifier i is defined, it cannot be changed _ 
VIMVAL is a single-assignment language. The treatment of variables as identifiers for values as 
opposed to placeholders for memory cells which may be arbitrarily, mutated as found in more 
conventional constructive languages i isa distinguishing characteristic of VIMVAL, 


A module in VIMVAL is a function which may be invokéd from other modules or by a user 
command to the system. A module -provides a mechanism ‘for grouping related functions 
together. These functions may be invoked from within the moddle or, if they are passed as a 
result of the module; by functions externat to the module. Thé-bédy:of a module may use names 
that are not bound by definitions in the module. These free names must be bound before the 
module can be run. Modules may be separately compiled with‘ type consistency of identifiers 
- used across modules being checked by a linker. . Type specifications are optional in VIMVAL. 
Omitting type: definitions allows free names in modules to be-bound in possibly several contexts, 
each binding causing a.different resolution of the types of the free variables.. Users can, thus, 
express useful polymorphic functions using the type inferenee méchanism. For a more detailed 
exposition on the VIMVAL language, the reader should see [13] and (28}. 


2 2 The Vim Interpreter 


The base language for the VIM system is the language of dynamic data. flow graphs. 
Programs written in VIMVAL are translated into their data flow. graph representation. Base 
language programs are evaluated by the VIM interpreter. A dynamic data flow graph is a 
“directed acyclic graph in which nodes represent base language instructions and arcs are used to 

"indicate data dependencies among instructions. There are two types of arcs in.the graph: value 
arcs and signal ares. An arc (s. fis a value arc if it carries the value produced by the execution of 
node sto node z A signal arc is used for performing a controt function such as selecting which 
arm of a conditional expression is to be evaluated. A node is said to be enabled if and only if it 
has reccived all necessary values and signals. Enabled instructions can be executed in any order 
and the interpreter is free to choose the execution of any cnabted instruction from any current 


function activation, 
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To illustrate the structure of a Vim data flow graph, we show in Fig. 2 the base language 
representation of the VIMVAL function shown in Fig. 1. Instructions are drawn as boxes, with 
the opcode of the instruction labeled inside the box. Value arcs are drawn from the bottom of. 
the instruction which produces the value to the appropriate operand slot in the target instruction. 
Thus, operand number one for an instruction will be sent along the leftmost value arc entering 
that instruction. Signal arcs are drawn entering into the side of instructions. Each instruction has 
an index in the activation used for addressing purposes, The behaviour of the base language 
instructions are described in greater detail later in this chapter. ae 


Function f(x :boelean; h, g : Function returns int) 
if x = true 
then A(1) % Aretufns an integer. 
else 9(2) % g returns an integer. 
- endif. 
endfua 


Figure 1: A simple ViwVat program 


Any non-scalar value produced during the evahation 0 ofan activation is sis on the VIM 
heap. The objects which may be found on the heap inctude function templates and data 
structures such as arrays and records. Associated with every object is a unique identifier, uid, 
which distinguishes this object from every other object on the heap. Thus, unlike’ simple scalar 
values, data structures and fiinction templates are fot” ittiinined along value arcs in an 
activation. Rather, the result of producing a complex structure. is, to. plage this. structure, on the 
_ heap and to send its uid to. all target. destinations. instead. --Vim-employs a-reference- count 
mechanism to manage the heap.. When there exists no.reference 40,4 steucture onthe heap from 
within any current activation, that structure can be removed. fram, the heap and its space reused. 
_ The VIM heap may be considered to be a multi-raoted, directed acyclic, graph where an arc (s, 2), 
connecting nodes s and é, indicates that ¢ is a component of, 5... ements on the. heap may..be 
safely shared among objects. This feature is a result of the. applicative: nature of the base 
language. An object on the heap consists of a unique identifier and a structure value. 


A distinctive feature of VIM base language programs is that no.arc in the graph is ever 
reused. This is a consequence of the graph being acyclic with tail recursion uscd to model 


iteration. This model of data low graphs requircs that every new function application create a 
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~ new copy of the fumction’ tetnptateantt in thts sete llbe thdtight OF as'a simplification of the 
“tagged: token dynami¢ dita’ flow ithiddel’ dled ‘tn’ Whe UAHieh sete? Be When a ‘unetion is 
instantiated.’the copy of tHe Fumetion ‘is: gfhiPlbd’ di the oll’ of applicatio 
 retums a resifft.’ the activation ‘grtiptt corerscts wih te ali ng sent to ail ea target 
‘instructions We itistrite his ie 3. PE SEED 


a. 
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- 1 Before APPLY ta executed - 


3. After activation completes with return result», tee 
Figure 3: " Function application in Via 


2.3 The Vim Shell 


Users communicate with the VIM system thrapeh a syste, Shell. The VIM shell is 
responsible for accepting user commands, and! translating. them into the appropriate base 
language representation and then invoking the interpreter to-precute this base language program 
whenever necessary. A user session typically consists of the biser communicating with the Shell 
in an interactive mode, inputing Shell commands whose Fegplts are subsequently output to the 
user. Every user executes in a unique environment. A VIM A environmedt relates symbolic names 
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to values and acts as.a. repository for all long-lived ¢ objects: ‘Objects referenced i inan environment 


ohamitned ¢ 


must be explicitly deleted by the ‘user. The VIM ‘environment plays’ the ‘role of. a directory 
‘structure in conventional systems. Users specify that a particular <name, value? pair is to fe 


pliced in his environment t through the BIND b command. ‘The user rcommand: | 


yf rj Fy Sian 


BIND name := espiecion 
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binds the value of the expression to the name specified: -This binding is then placed in the user’s 
environment. In addition to the BIND command, there is a DELETE command which, when given 
a name, removes the «name, Value binding from the user's environment. The command: 


DELETE N 


removes the binding, <N, Value» from the current envitonment, Users must execute a DELETE 
command to have an entry in their VIM environment removed. 


The VIM shell translates a BEND signtiand into its base language, representation which can 
then be executed by the VIM Interpreter. The translation for the command BIND x := {(2) is 
shown in Fig. 4. The APPLY instruction creates an activation of the function f with argument z. 
The result of this activation is sent to a special instruction, TERMINATE, which informs the shell 
that the value which is to be bound to the name.x is avgilable. The storage occupied by this top 
level activation can then be reclaimed by the syste wsing the RELEASE instruction. Thus, once 
the value which is to be bound to the symbolic tame i is known, the activation created oy the shell 
can be removed from the system. 


| TERMINATE 


Figure 4: The translation of the BIND command — 


There is no translation into a base language Program necessary | | for the D DELETE sonia This 
command is processed by the shell sakes —— no assistance is required from the NED ICES to 


execute it. 
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The TERMINATE instruction ‘described above ‘is ised to synchronize the operation of the 
interpreter program with the shetl: ‘If this synchronization mechanism were removed and BIND 
commands were allowed to arbitraily ‘overlap with one ‘another, “ft is possible for incorrect 
environments to be constructed. To see why, consider two BIND commands input in succession: 
BIND(x, F) and BIND(x, G). It is clear that if the commands. are. processed :correctly, x should 
finally get bound to the Tesult of evaluating G. To, ensure. that.this, ‘pexialigicion takes. place, 
however, requires that the Second BIND command dogs not occur until the first one completes. 
As we shall see later, it. is possible to still exploit.a great amount of. concurrency by. allowing the 
computation of F ta be still proceeding even if BIND (x, f) executes. This feature, known as early 

completion, is described in section 2,4.2. _ 


In the next section, we will present a formal eiuemlue for the VIM oe 
considering, for re internal representation of data “agus, in Memory, paging. of 
structures to and from memory or scheduling algorithms, ‘We make two simplifications of the 
actual system in our model. First, we assume that all coffiputatidd in the system is iererminate. 
A computation is determinate if its output is totally specified by the value of its. inputs; it’s 
output does not depend on such factors as the relative arrival time of its inputs. Secondly, we 
assume that only a single environment exists in the system and, thus, there is no need for 
providing an explicit environment name to. those instructions which manipulate environments, 
In the following chapters, we shall refine this model to describe the backup and recovery 
algorithms. | - —_ = 


2.4 A Formal Operational Model - M1 


The VIM system contains three major components: an Interpreter, a system State and a 

Shell. The State embodies ali current information in the system ie, heap, activations, enabled 

instructions and enviroaments, The. interpreter executes a ‘base: language representation of a 

Shell command and returns the value of that.command, The: value sewrned by the interpreter is 

_ bound to a symbolic name.in the user environment. The:name being: bound. is determined by 
_the current BIND command being processed. :A shell command: is translated into its base 
language representation and is. then executed by the interpreter. This teanslation:is performed by 

the Shell. The shell as described above is.a function mapping from a State and a session to anew 


State. A session denotes the history of SAc// commands input to the system. The shell translates 
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shell commands, invokes the interpreter to execute. these. commands in. the current state, and 
binds the result of these commands to names in the user environment. It returns the state which 
is produced after evaluating all shell commands in the.session. The abstract architecture of the 
VIM system is shown in Fig, 5. 


In the following discussion, sets are denoted by bold font, elements of sets are denoted by 
italicized letters and names are indicated by a script strings of letters. Thus, Set is a set, Eit € Set 
and tag is a tag. We present our semantic definitions using ViMVAL-like syntax augmented with 

“operations for performing set abstraction; set membership, etc. ori the domains defined below. 
Function domains are specified using arrow (—) rotation. Thus, the domain equation, 
A = B — C defines A to be the set of all functions with dothain B’and range C. Tuples are 
enclosed using angle brackets. 

- Formally, we define the VIM System to be a three-tuple: | 
VIM = <Shell; Interp, State> where | 

State = <Act xX H x EIS x Env> 

Act = U, — Activity 

 H= Uy — ST 

U, = the set of unique identifiers used for activations. 

Uj, = the set of unique identifiers used for structures. 

EIS = the set of enabled instructions, described later. 

Env = Name — (U U Scalar) | 

Activity = N — Instruction, N being the set of natural numbers. 
An element Act in the domain. of VIM activations, Act; is a mapping from unique identifiers to 
activities. An activity is a function mapping from natural numbers to instructions and represents 
the code of an activation. An activity can be thought of an array of instructions, the #* element 
in the array specifying the 7” instruction. The Vim-fieap, H, is‘moueled as a function from 
unique identificrs to structure types, ST defined below. The structure of the heap is determined 
trom the mapping defined by the heap function. Scalar values are not represented on the heap. 
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Activation 


Instructions 
: 


value 


Figure 5: The Abstract Vim System 


New State 


Teo 


Environment component | in the State i is also a “function, mapping | from a name, which is ‘any 
sequence of characters, to either a unique identifier referencing a structure on the heap or a 


“ scalar value. 


The data types supported by the system are given below: 


Scalars = Integers Reais .3 Booleans U Character Null: -. 


‘Name = Character’, ‘the set of all character sequences 


Integers = the s set of all integers U. undef} 

‘Reals = the set of all reals U {undef} 

Booleans = {true false, uhdeff- — 
Character = the set of characters in the machine U { undef} 


Null = {nil. undef} 
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ST = {ArrayU{undef}} U {RecordU {undef}} U {OneofU{uade/}} U {Function} 
U {ECQ} U {Clsr} U {Dests} 


Array = Z — (U,, U Scalars), Z being the set of integers. 
Record = N — (U,, U Scalars U SUSP U Dest), N being the set of natural numbers. 
Oneof = N — (U,, U Scalars U SUSP), N being the set.of natural numbers. 


Function = N — Instruction, N being the set of natural. numbers. 


The set of structure types includes arrays, records, and oneofs. Arrays are modeled as functions 
from integers to either unique identifiers representing structures on the heap or scalar values. 
Records are modeled as functions from natural numbers to either unique identifers representing 
some structure on the heap, scalar values, suspensions, which we describe later, or destination 
lists. As we explain below, the return address of an activation is packaged into a record and 
transmitted to that activation when it is instantiated by the APPLY instruction. The destination 
list represents the list of return addresses which are to receive the result of the activation. While 
components of record structures are addressed by their fiekt-name in VIMVAL, the compiler 
translates these names to the offset of the addressed component in the record. a 


Note also that the set of functions is also included among the elements of the structure 
types in the system. This is consonant with our treatment of functions as first class citizens, An 
element of type F unction is a mapping from natural numbers to instructions just as elements of 
the set of activations are. As we shall see below, the only difference between a function 

- définition and its corresponding activation is that the latter is sensitive to the effect of i instruction 
execution since operands and signals are received by the instructions within an activation 
whereas a function is a pristine object like any other VIM structure. 


A function closure is a special record of two components: the first component is the uid of 
the function template of the closure and the second component is the list of free variable 
definitions found in the function. The closure of a function completely defines the bindings of 
the free variables in the function and, thus, must be: defined before. the function can be applicd. 
Free variables are accessed by its indcx in the free variable ist. The. definition of a eee is 


given formally as: 


Clsr = <U,, X(N  (U,, U Scalar))> 
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2.4.1 The Base Language Instructions _ 

A base language instruction is an seven-tuple consisting ofan opcode, three operand fields 
_ {not all need be used), an operand-count used: to: indicate ‘ow: mary: operands triust arrive, a 
. Signal count used to indicate how many signals: must:be:réceived;. and the: destination tecord 
containing the list of destinations for this instruction. The set-of opeodes we will be considering 
in our operational model will include . record- stractare: operations, function application 
instructions, and operations om early completion elements, < These classes Of instructions will be 
the ones of greatest interest when.we present our backup rey: ee 


Instruction = OPS x (U,, U Scalars)’ x xNXN' x Dest 


A destination has a type. which is either. Luncondistondl: the:resule of the instruction. is to be 
sent automatically to the destination, true or false used: by:a. SWITCH. instruction to: control 
conditional evaluation. If the type of the destination i is true, then the result i is a signal which is 
"sent to the déstination instruction if and only if the swiicH operator evaluated to true. Asimilar 
~ description applies for a false type destination. All destinations ofa an instruction must be within 
the same activation. The second component of a destination is the instruction number to which 
“the signal of result value should be sent. If the destination i is to receive a a signal, then this must 
be specified. Otherwise, the operand field to which the result is to be sent n must be provided, 
For convenience we shall refer to the elements of an instruction using dot, notation. For 
example, the opcode of instruction / shall be denoted as L.opcode etc. 
Dests = %(D) 

~D= junenig, ‘true, false} xNX x {op t, 072, 078, ‘signal 

An enabled instruction is a two-tuple u. d) representing-an scslinalicall in-some activation which 
has received all necessary operands and signals. Any enabled instruction can be executed by the 
interpreter. The applicative nature of the system guaraneeés thatthe Dehaviout of the program 
will be determinate regardieas.of the.order in which. enabled’ instructions inthe program are 
executed, aan 


El = <U, X ND. 


EIS = (El) is the sct of enabled instructions, 
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2.4.2 Early Completion Structures 

According to the model of operation presented above, an-instruction is allowed to execute 
only when it receives all necessary operands and signals. In the case when. an instruction is to 
operate on a data structure such as an array or record, :this means that the entire structure must 
_ be fully constructed before this instruction.can execute. If the iastruction only needs to examine 
a certain portion of the structure, then the execution model unnecessarily constrains parallelism 
in the program. To alleviate this problem, there is a facility im VIM: known ‘a3 early completion. 
Early completion structures allow greater concurrency of operation by allowing a data structure 
to be constructed and used before all of its components are available. The compiler designer.can 
use this facility, for example, to generate code which will cause the results of an activation to be 
- an early completion structure to allow the: oot, ‘activation ‘to use. some of the results of the 
callee before all of them are known. 


An element of the set ECQ is an early completion element ju. An early completion 
element is a two tuple, (u, i), where ue Uy and i € N. The early completion structure is 
essentially a queue containing target addresses of those ‘instructions which require the value of 
this element in the structure. When the value is finally produced, i it will replace the ec-structure 
and will be sent to all targets. This process is illustrated i in Fig. 6.. 


ECE = <U, X ND. 
ECQ = 9(ECE) 


An element, (u, #) € ECE denotes an instruction which. has Tequested the value which is. ‘to 
replace this early completion structure. The uid u ‘denotes a function activation, and / is the 
index in.this activation of the target instruction. 


2.4.3.Delayed Evaluation Using Streams 


The astute reader. would have noticed that the stream type presented in an earlier section is 
not defined in our formal model. We represent streams using the record and oneof types: 


Stream[T] = oneof 
[empty : null 
non-empty : record 
[first : T 
rest : Stream[T]]] 
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R.& is an early completion structure whose value is SET by instruction B. 


Heap: 


A; 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


vy. After B executes, value of R.k is sent to all targets. 
vl v2 v vk | 


Figure 6: The Use of Early Completion Structures 


We have previously mentioned that streams are potentially infinite structures, In a purely 
data driven execution model, the production of a stream may far outstrip its consumption. To 
avoid wasteful computation, streams are produced in a demgad-driven {ushion [16]: In demand 
driven evaluation, an element of a stream is produced only when its. consumer requires it. To 
| implement this feature, a special record element called a suspension, is, is introduced. A suspension 
contains the address of the instruction in ‘the stream producer reponse, for insanuating 
’ becuifies replaced by an n early completion queue. and a signal i is, sent to > the he which t the 
suspension holds. A new record is created for the next element and the carly, conjpletion queue 


will get replaced with the uid of this record. The head. of this new record will contain the new 


Activation 
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stream element and the tail of this record will again hold a suspension. We illustrate this process 


graphically in Fig. 7. 


1. Stream § with firs(S) = y. , 2. After suspension accessed, it becomes an ECQ. 
$s s 
: , Pacg Ta) 
Producer (ui) is the consumer instruction 


3. Producer yields next element which is transmitted to waiting consumers. 


Figure 7: Demand driven evaluation of a stream using suspensions 
SUSP = <U x ND 


The suspension structure is a pair <u, which represents the address in the stream 
producer that is to be signalled when the suspension is accessed. 


2.5 Semantic Functions for M1 


In this section, we present an operational model for the VIM Shell, Interpreter and base 
language instructions which extends the operational model defined in the previous section. The 
instructions which we examine here are chosen because of their relevance to the backup and 
recovery algorithms developed in the following chapters. “We partition our presentation into 

“four categories: formal description of the Shell and interpreter, instructions which operate on 
structure types, instructions which are used for manipulating early completion structures and 


stream clements, and instructions which are concerned with function application and return, 
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“In the next section; we define’ sore auxilidry furictions that will be useful for our 
ptesentation. These functions are used in the definitions of the above mentioned base language 
instructions. 7 : 


2.5.1 Auxiliary Functions 

There are several primitive auxiliary functions which’ we'need-to define before presenting 
our operational model. “Phése: functions operate ‘oni ‘the ‘héap, activation; ‘and environment 
components of the VIM state. The functions NéwHeap) Renibverfedpadds and remove an 
element to and from the heap respectively. The  NewHeap function takes i in three arguments: a 
current heap H, a uid u, and a structure, v. It returns anew bean: H’. identical to H except that 
this new heap is defined for-u suctr that: Hu) = ». This definition of ‘New#eap allows us to 
rebind existing uid’s to different values, a featuce which will be-usefel when implementing early 
completion structures and suspensions as we shail see later. The RemoveHeap function takes as 
arguments a heap H and uid u, and returns a new — HH’ identicat eH except that H’(u) is 
undefined. 


NewHeap: H X U,, x ST +H 


Function NewHeap (H, u, v) 
V u, € U,, let ke Mu) ita eu 


in 
H’ 
endlet 
endfun 


RemoveHeap: H X U,, + H 
Function RemoveHeap (H, u) ee 


Vu, € U y kt H(u,) = A(u,) if u, * u 
= eon otherwise 
in 
HW’ 
endict 
endfun 


There are similar functions, AddAct ind RemoveAct defined for the activation component 


of the state and AddEnv and Removelny defined for the environment component as well, 


seh en 5 ST RT af, he gen ag 3 Pagan, ge ae Sa at ree ae A tes et 
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Since the transmission of results and signals is an activity.common to every instruction, we 
define an auxiliary function, SendToDest which is responsible, for sending a value or a signal as 
the case may be to the specified target instruction and constructing a new activation function and 
new set of enabled instructions to reflect the effect of this transmission. SendToDest constructs a 
new activation component in which the target instruction found in the:destination argantent has 
been updated to reflect the transmission of the value or. signal, Af, .a6.a'reault of this transmission, 
the target instruction becomes enabled ie, have its opens and sigcnt fields become zero, that 
instruction is appended to the enabled instruction. set. 


ResultType = Wy U Scalar) U signal 
SendToDest: Act x EIS x U,x Ds RemitTigiss Ant HS 
Function SendToDest Act, E1S, es a <de, i — result) 


let FA = Act (up) 


I = FA 
resultval = if result = signal 
then undef 
else result 
endif 


newopnum! = if opnum # op! then J op}. else resultval.. 
newopnum2 = if opnum # op2 then /.op2 elsé.resudtnal - 
newopnum3 = if opnum # op3 then /.op3 else resultval 


newopcnt = if result = signal 
' then Lopent 
else Lopent-1 
endif 
newsigcnt= if result = signal 
then /sigcnt-1 
else /sigcnt 
endif 


[= Lopcode X newop! X newop2 X newop3 x newopent X newsigcnt X Idests 


ViENFAQ() = FA), j#i. 
= [ j= 


NewAct = AddAct Act. u ra © A) % new sct of activations 
NewLis = if (opens = 0) A (1 Sigent = =). 
then EIS\ U (up, OFS 
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ele EJS 
endif 
in 
NewAct, NewEis 
endfun. 


Two functions which call SendToDest are SendValue and SendSignal. The function 
SendValue calls SendToDest for every target in the destination list of an instruction whose opnum — 
is not Signal, That is, all target instructions that are to‘ receive’ ithe: result of the instruction are 
sent the result value by SendValue. This operation is accomplished through the use of 
SendToDest. SendSignal operates in a similar fashion: tw SendValue except that it calls 
SendToDest for all targets in the destination list of an instruction whose opnum is signal. 


SendValue: Act x EIS x U, X Dests x ResuttTypa.~+ Agt x. EIS: 
Function SendValue (Act, EIS, uy», dests, v) , 


let ValDest = {<dc, i, opnum> € deme orreume € satiate moat 
<de,, ‘v opaurn, >, Kee by 
OPNUM,D, ...5 <A» ing opnum,> = = 
ncomponents of ValDest 
in 4 aot 
SendToDest 
SendToDest... 
SendToDest Act, EIS, Urge <dey, a ‘aii » 
u op! Wadd. 2 
js Fat SMa bp OPH, 
endfun 


SendSignal: Act x EIS x U, x Dests X—+ Act x EIS — 
Function SendSignal (Act, EIS, up» dests) 


let SigDest = {<de. i opnum> € dests | opnum = ‘= signal} 

<de,, iy. opnum,>. <de4.k,0pnum,>, . = tn , opnum,,> = 

m components of SigDest” 
in 
SendToDest( 
SendToDest... 
ie oDest( Act, EIS. u,.4- <dey, iy. opnum,>. signal), 
Fa Sey. b>. opnum,>. Signal)...) 
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endlet 
endfun 


2.5.2 A Formal Model of the Shell 


§2.5 


As we described above, the VIM shell serves as the interface between the interpreter and 


the VIM user. The formal definition of the shell is given below: © 


Command = C xX Name x (Exp U undef) 
C = {BIND, DELETE} 


Session: Stream[Command] 
Shell: Session x State — State 
Function Sheil (Session, State) 


let <Act, H, EIS, Env> = State 
NewState = 
if ChooseToE xecute (State, Session) - 
then ShelK Session, Execute (State, Choose EIS))) 
elseif empty(Session) 
then State “ 
else a = first( Session) 
in i C}. .C = DELETE 
then <Act, H, EIS, DelEnwEnv, Name)> 
elseif C). .C = BIND. 
then let % coritmand:is BIND 


FA = Translate(c,) 
Up, = = new tiid from Uy 
Act’ = Add Act Act, Ung FA) 


NewEIS = EISU {due S | FA().opent = 


A FAO = 


State’, v = Interp\ State, Choied NenE1S) 


<Act’, H’, EIS’. Env> = State’ 


in 
<Act’, H’, EIS’, Env> 
endiet 
endif 
endict 
endif 


Env’ = AddtoEnv (Env. c, C..name, v)- 


3 ne Ge HME PENS CYS See ists sop eipee te Maa ia Bue SE ode ab OPE OR gt 
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in 
if empty (Session) 
then if E1S’# {} 
then- Shell (Session, Executed Newsiate, Chtet189) “ 
else Newstate 
endif 
else Shell (rest(Session), Newstate) 
endif 


endiet 
endfun 


The shell takes in as-input a stream of ‘shell eoinmands. “It calls the function 
_ ChooseToExecute.which:-examines the .cufrent state ‘aid stalin’ ‘and determines if the shell 
should process the next shell command or whether it should call the ‘#xeezte function using the 
current enabled instruction” set” This function “allows ‘the system to continue to process 
instructions even if the remainder of the session. bas: Bot yet-besasinpud by. the waer.- One possible 
implementation of this function would be a routine which Snare the pattie input buffer — 
if the buffer is empty and there are ‘instructions ‘still to be ome. it returns true. If, on the 
other hand, there are shell commands available to be processed, it returns false. In the case when 
there are both commands and enabled instructions avaifable, it can arbi it , rily retum either true 
or false. If the function returns false and the fire. oonmmand ja the:commend stréam i is DELETE, 
then the shell removes the Cname, value» bindifty Trt the clitrent‘environment and processes 
the rest of the command stream. If it is a BIND command, Rewewer, it-cellgan auxiliary function, 
Translate with this command stream element. Trahsttice Vetaens an: ‘activity, Pa, ‘which embodies 
this command. For example, if the commaiid “neat ta to ele wes | BIND: &x. = S(), the 
activity returned would be of the form shown in Fig. 4. The result of evaluating this activity 
represents the value of the command. A new activation is constructed from this a activity and this 
activation augments the current activation state. The enabled instruction component is also 
appropriately augmented 10 inchuce alf-trtscructions‘in this wew activiition that Have tlieir operand 
and signal count already.zero. “Fhe shclf cally tte Stiterpteter-4tt this new ‘state and’ some 
enabled instruction’ front ‘the set -of | onabled ingenutlons, “Phd choice: of which -eriabled 
instruction to.execute:is made’ by ‘the Chulee function > Pue-new mate Hcrned by' the interpreter 
is used by the shell.in- processing the-next shell compimind # there-afe any mdre to be processed. 
The value, y.. reared by the interpreter is‘bourd if’ tie user énvitatimentto'the symbolic name 
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which is an argument to the BIND command. If there are no more stream commands to be 
processed, the shell calls the Execute function described below to execute the remaining 
instructions found in enabled-instruction set. If there are: no. more. enabled instructions, the 
function returns with the final state. 7 ae 


2.5.3 A Formal Model of the Interpreter 

The interpreter is a state transition function from states and enabled instructions to a state 
and either a unique id or a scalar value: . 
Interp (<Act, H, EIS, Env>, Choice EIS)) ~ <Act’, H’, EIS’, Env> X (U fra") Scalar) 
The Choice function, as we explained. above, is used to, determine: which enabled instruction 
should be chosen for execution from the enabled instruction set. The. definition of the 
Interpreter is given below: -_ 


Interp: State X EI — State X (U,, U Scalar) 
Function Interp (State, <u, D) %Ku, D> is an enabled instruction | 


let 
<Act, H, EIS, Env> = State 
FA = Achu) 
Newstate = Execute(State, Cu, D) 
<Act’, H’, EIS’, Env> = Newstate 
in 
if FA().0pcode = TERMINATE 
then Newstate, FA().9pnumi 
else /nterp(Newstate, Choice EIS *)) 
endif 


The instruction which is chosen for execution must.be part of some activation defined. in 
the set of current activations, Act. The interpreter callsion an auxiliary function, Execute, 
defined below which contains the definitions of all the base language primitives. Note that the 
interpreter only returns its result when the TERMINATE instnaction Bas.executed. This restriction 
guarantees that environments will be: updated correctly according to the order in which BIND 
commands were input. When the interpreter returns,.a new command can. be processed by the 
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shell. Note that because of the presence of early completion structures, there may still be many 
- activities in progress at ‘the time the TERMINATE instruction executes and ‘the next shell 
command is processed. Thus, our model atfows instnictions' found in’attivities created from the 
evaluation of different bind commands to execute in parallel’ We do not come into problems in 
earlier, bindings are. always 


augmenting environments though, because, as we discussed. 
constructed in the Proper serial order. 


The Execute function examines the instruction being processed and performs the necessary 
function. The:result of this function will bea new VIM state. ‘The structure of this function can 
be given as follows: 


Execute: State X El -» State 
Function Execute (State, <u, 4, kp ) 


let <Act, H, EIS, Env> = State 
FA = Actu, 4) 
P= FA(k ) 
destinations = I.Dest, 


NewEIS = EIS- (upp kp} 
in 
if Lopcode = SET then... 
elseif opcode = APPLY then... 


endif 
endiet — 
endfun 


The destination list specifies those instructions in the current activation to. which | the result 
of executing this particular instruction should be sent, ‘Recall ‘that j in n addition to transmitting 
results, we may ao need to send signals to destinations, 
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2.5.4 Formal Definition of Base Language Instructions 

In this section, we present a formal definition of those. base language. instructions that will 
be useful to us in describing the backup and recovery algorithms later in the thesis. Keep in 
mind that these definitions aye actually found within the Execute function given above. 


2.5.4.1 The TERMINATE Instruction 

The TERMINATE instruction is used to receive the result of evaluating a base language 
program. This result.value is then bound by the shell in the user environment. The instruction 
takes in one argument, which is either a scalar value or a:uid.. it sends no:results but will send a 
signal to a RELEASE instruction which is used to remove the activity from the set of current 
activities. We describe the operation of the RELEASE instruction fater in the chapter. The 
interpreter picks up the result from the first operand slot ir in the instruction when it returns back 
to the shell. 


if opcode = TERMINATE then 
let 
= H(Lopt) 


Act’, NewEis’ = SendSignak Act, EIS, up, destinations) 


in 
<Act’, H, NewEis, Eny> 


endlet 
endif 


2.5.4.2 Structure Operations 

The base language contains. powerful instructions for the creation and manipulation of 
structure types. There are three structure operations of particular interest - CREATE, REPLACE 
and SELECT. The CREATE operator is used to create a structure of a particular dimension. Ina 
functional language, a structure, once defi ned, cannot be subsequently altered. Replacement of 
an element a in a structure with an element Bi is done by creating a new version of the structure 
with B replacing a@ in the new version. The SELECT operation returns the value of a specified 


field in a structure. 


The operations we describe below are for the record structure type but are very easily 


converted for the array or oneof type. 
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To create a record structure, we have a MAKEREC instruction. It takes in one argument, the 
size of the record structure to be created and constructs a record of such a dimension, setting all 
the fields in the record to be undef. In addition to the MAKEREC. instruction, there is also a 
MAKERECEC instruction which constructs a record, afl of whose elements are early completion 
structures. 


if opcode = MAKEREC then 
let 
m= Lop! % misa natural number 


= anew uid in. Uy 
Act’, NewEis’ = SendValue( Act, EIS. u 4, _ destinations:u)) 
Act”, NewEis” = SendSignak Act’, ros aration 
H = NewHeaplH, u, MakeRecord, sie . 
in 
<Act”, H’, NewEis”” , Eny> 


endlet 
endif 


The REPLACE instruction on records takes in three arguments; ‘the uid of a record R, the 
field in the record which i is to be replaced, f and the value. of tbe, new element, x, which may be a 
scalar or a uid. It creates a new copy of the record, R’, with field fin this copy having value x. 
We mention the REPLACE instruction here mostly’ for complet efiess as it will not be involved in 
the design of the backup and recovery algorithms we develop’ laten inthe thesis. For a detailed 
semantic description of this operation, the reader should see [17]. 


The SELECT iristruction is given a record structure and the offset in the record of the field 
to be selected. If the item to be selected is.an early. completion. structure, then. the instruction 
queues itself onto the ec-queue. When the value of this field is Meee known, the. select 
instruction will be placed again on the enabled instruction queue so that i ee may execute. It is also 
_ possible that the item being selected may bea suspensitit f thé redGril'ts part of'a stream. Recall 
-that the rest operation: on‘streams is translated ‘into a ‘Select’ operation on the second component 
of the head of the current stream. ‘Because streams are produced ‘in a demand driven manner, 

this fickd may be-a suspension in which case the SELECT instruction wil neéd to send a signal to 
the instruction referenced’ by the suspension. The field occupied by the’ suspension will then get 
‘changed to an early completion queue which will get SET it ‘the activation ‘responsible for 


producing the neat stream clement. 
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if opcode = SELECT then 


let 
R = Hopi) 
f= lop2 % f must be a natural number 
t= RY) 
Newsiate = if t€ U,, A H() € ECQ 
then <Act, 
NewHeaplH, t, H()U {Cup 4° kee) 
NewEis, 
Eny> ls 
elseif ¢€ U,, A H() € SUSP 
then let 
<u',k> = HO 
Act’, NewEis’ = 
SendToDest( Act, NewEis, u’, <uncond, Eeiplabs signal)) 
in 
Act’, 
NewHeaplH, t, MakeECQ (Xu,, k-,>)) 
NewEIS’ ee 
Eny> 
endlet 
else let 
Act’, NewEis’ = : SendValue{ Act, NewEis, u ge destinations, d 
Act”, NewEis” = = SendSignal{ Act’, NewEis. ri rar destinations) 
in ; 
<Act”, H, NewEis”, Enw 
endlet 
endif 
in 
Newstate 
endlet 
endif 
2.5.4.3 The Set Operation 


The main operation on early completion elements is the SET instruction, The instruction 
takes in three arguments. a record R, an offset in the record which sepresents. the field which is to 
be set, and a value, x. When the set instruction. executes, it. replaces. the early compiction 
structure found at the specified component with: x... -Moreover, all the. elements in the 
ec-structure are appended onto the enabled instruction queue since: the value of the field which 
these instructions initially requested is now availuble.. The SET instruction, unlike the REPLACE 
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_ Operation mentioned above, does-not cause a new version of the structufe to-be created. Instead, 

_ the early completion structure is. replaced with the value in: site, This ‘does not violate any 
principle of referentiai.transparency because.no instruction ts allowed to read a field which ts an 
ec-structure. Since the SELECT instruction on structures prevents any of its targets from Treading - 
the value of the field until it ts property set, the applicative Property of the base Janguage i is not 
compromised. Because all instructions which require the ‘value of this field are.on the early 
completion queue, SET does not send any results to any of its destinations, oat signals. 


if opcode = SET then 
let 


VvEN 
Ry) = RO) ifvaf 
= x otherwise 


Act’, NewEis’ = SendSignaK Act, NewEis, uy, destinations) 
H= NENRIT a +R) 


in 
<Act’, 
H, Sas Se 
NewEis’U H(u') 
Env> 

endlet 

endif 


2.5.4.4 The Suspension Operator . 
: "ls seca var Gpacinls 6 sammonslbls Gc Sasiag's saasateibn da eeasiina Suecae! It takes 
in three arguments, accord siruckure rapreseating the-head of the current stream; an offset into 
-this structure. where. the suspensign is to be placed. and ai instruction iaddress. 4 representing: the 
instruction which is to.bc signalled when: the suspension isacoeised: ‘The. offset must be an early 
compiction element presumably constructed by a.MAKERECEC instruction; SETSUSP sets én: this 
record the value, <u,.4. 2. up, being the uid. of the activalion in-which the SETSUSP opcrator is 
exccuting. If the ec-structure is not emply,.then SETAUSP:signalstht activation us weil since:such 
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a situation implies that some select operation has already ‘attempted to read the next stream 
element. Like the SET instruction, SETSUSP does not send any. results. The instruction is only 
used in the translation of the VIMVAL operator, affix, which is. responsible for the construction of 
streams. . 


if opcode = SETSUSP then 
let 


i= Lop3 
Act’, NewEis’ = SendSignak Act, NewEis, uy .4: destinations) 


VvEN, 
Ry) = Riv) ifve Sf 
= MakeSusp{<u;. A D) otherwise 
in 
if RQ(EECQAIRG|=0 
then <Act’, 
NewHeap(H, u, R’, 
NewEis® 
Env> . 
else let Act”, NewEis’= noe. 
SendToDest( Act’, NewEis’, u,,, Suncond, i, signal>, signal) 


in 
<Act, H, NewEis”, Eny> 
endiet 
endif 
endlet 
endif 


2.5.4.5 Function Application and Return 

The instructions which will be of greatest interest to us in the coming chapters will be those 
concerned with the manipulation of functions. There ate four instructions in Vim which deal 
with this: APPLY, TAILAPPLY, STREAMTAIL, and REPURN. The APPLY instruction is the standard 
function. application instruction, taking a funetion closure ‘afd: ‘an’ argument record ‘and 
constructing a new activation for this function. By convention, the first operand of the first 
-instruction in the activation receives the closure of the function, thus‘ alfowing the activation to 
access the free variables of the function, the first operand of tfie. second instruction receives the 
‘argument record, and the first operand of the third instruction in the activation receives the 
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_ destination listof the APPLY operator.. APPLY uses an auxiliary function, MakeDest which 

- packages the destination entries found in the destination: list of the instfuction into a record and 
. places this record on the heap. MakeDest takes in three argements, the current -heap; the uid of 
_ the current aetivation and the destination component of the instruction: ‘It retums a record, a, of” 
_ -two elements, the first element contains the uid argument and the second contains the tiid of the 
record containing the elements found. in the destimation list. The uid of a is passed as an 
argument to the called activation. Placing the destination components into a-record allows. them 
to be accessed by the RETURN instruction in the called activation. 


if opcode = APPLY then 
let 
C = Lopi 
arg = Lop2 


<u,, free> = H(C) 


u’ = anew uid from U,, 
u”-= anew uld from u 

Act’ = AddAct Act, u’, u,)) 

H’ = AddHeapH, u, MakeDest( H, Mra I.destiist)) 


Act”, NewEis’ = 
SendToDest 
(SendToDest 
(SendToDest 
(Act’, NewEis, u’, <uncond, 1, aE C), 
u’, <uncond, 2. op), arg). 
u’, <uncond, 3, op)>, u’) 


in 
<Act’, H’, NewEis, Env>. 
endlet 
endif 


There is no explicit iteration construct in either VIMVAE or. the:base language. Instead, 
iteration is modeled using éail-recursive functions wheréin the result of thé iteration is obtained 
in the final recursive call. Otherwise. while the recursive call is being ‘processed, the calling 
activation would exist merely to route the result back to the caller. To avoid having the calling 
activation persist until the call is Complete, there is a special base language instruction for 
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handling tail-recursion, TAILAPPLY. The TAILAPPLY operator differs from the APPLY instruction 
in that it requires a third operand, which is the return address to which the result should be sent. 
By providing its own return link to the callee, the caller need not wait for the recursion to 
complete. We illustrate this process in Fig. 8. The tailapply. instruction sends only signals to its 
targets. Typically, the target of TAILAPPLY will be a RELEASE instruction, described below, 
which reclaims the space used by this activation. 


First k-1 activations can be reclaimed without waiting for subsequent calls to complete. 


Figure 8: Tail application in Vna 


if Lopcode = TAILAPPLY then 
let 
C = /opt, 
arg = Lop2 
dest = 1.op3 


<up fre) = H(C) 


u’ = anew uid from U,. 
Act’= AddAct{ Act, u- H(u,)) 


Act”, NewLis’ = 
SendToDest 
(SendToDest 
(SendToDest 
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_(Act’, NewEis,.u’,Suncond,1,opi>,C) ....... 
u’, <uncond, 2, op1>, arg) 
u’, <uncond, 3, op1>, dest) 


Act’, NewEis” = SendSignal Act”, NewEis’, u, 4, destinations) © 


in 
<Act’”’, H, NewEis”, Enw 
endlet 
endif — 


The STREAMTAIL instruction is similar to the TAILAPPLY operator in that both are used for 
implementing tail recursion. The STREAMTAIL | instruction, however, is aused in the 
implementation of a STREAM producer. Unlike | the TAILAPBLY operator, the return link 
argument to STREAMTAIL is a record fietd-in- the tast stream ‘element created. When the next 
activation of the producer is instantiated, this return ing will lage SET to the wid of the new stream 
element. Thus, while the destination of the TAILAPPLY Yinggguciion is is always an instruction, the 
return link of the STREAMTAIL operator must be a-record-field-of the last stream | element created, 
The basic structure of a stream producer using the STREAMTAIL ATL i instruct tio on is shown i in 1 Fig. 9, 


The RETURN instruction takes as input two arguments. list of feturn, addresses and a 
value. It sends to each of these retuns: adeiredses,:the specified value afid:therr sends signals to 
target instructions within its own Hoctinleresi Unlike any off er pase language instruction, the 
execution of the RETURN. operator, affetsinstguctinge, im: netivations, besides ‘its. own. Thus, 
having the RETURN operator execute may lead to instructions in other activations, becoming 
enabled. The value argument to the return instruction reprogepts-the yalue.of the. activation; no 
other effects of the activation will be visible outside of the- value sent by the retin ‘operator to 
the receiving instructions in the calling activation. This property is a. consequence ¢ of the 
applicative property of the base language. The RETURN naatne uses an auxiliary function, 
- GetDest, which: is the complement of the: MakeDeit RAIQIOA UciriBed editier. “ GetDest when 
aiven the :henp and the wid of the #etord: returns 8 set sdicsiceradigte Bestia list sanitt 


if opcode = ‘RETURN then 
et 
DOL = H(lopt) % the list of retarn addresses - 


u,= DL(I) % uid of the calling activation 
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closure = Arg. rec. 
STREAMTAIL 


| Figure 9: Skeleton of a Stream Producer 


targets = GetDest(H, DL(2)) 
val= Lop2, % the value.to be returned 


Act’, NewEis’ = SendValue( Act, NewEis, u, targets, val) 
‘Act’, NewEis™, = SendSignak Act’, NewEts’, u,; .. destina tions) 


in 
<Act”, H, NewEis’. Env> 
endlet 
endif 


The last instruction we shall. present is the RELEASE instruction. Unlike any of the other 
instructions presented thus far, RELEASE is not used: in.the implementation of any VIMVAL 
construct. Instead, it is used for memory Management purposes in the machine. When all 
instructions within an activation have completed. the storage oceupied by the activation may be 
reclaimed by the system. The RELEASE instruction performs this function. In a language 


without early completion structures, this operation. would: usually .be a. part of the RETURN 
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instruction, but because there may still be computations still in progress within the activation at 
the time the RETURN executes, it is necessary for a separate instruction to handle storage 
reclamation. 


if opcode = RELEASE then 
<RemoveAct Act, Ur 4) 


NewEis, 
Eny 
endif 


2.6 Summary 

In this chapter, we have presented a formal operational model for the VIM computer 
system. We introduced the application language, VIMVAL, and described the role of the Shell in 
the system. A rigorous definition describing the behaviour of some of the more interesting base 
language instructions was also presented. There are two key points raised in this chapter that 
should be noted. First, for the most part, an object created by an instruction is immutable. For 
those cases where it is not, as in early completion structures, the access and updating of these 
objects is carefully regulated to prevent incorrect information from being read. This feature of 
the system has major ramifications for the design of a backup system because it means that 
objects copied onto a backup storage device will, by and large, never need to be updated. The 
second characteristic of the system is the power of the individual base language instructions. 
Because of the expressive power of the base language, it should be possible to integrate the 
design of the backup and recovery system within the base language itself. The means by which 
this can be done is addressed in the following chapters. 


We are now ready to develop the backup and recovery algorithms for the system. In the 
next chapter, we give a general overview of the approach we take in designing these procedures 
and the enhancements which need to be made to the system in order to support them. In 
subsequent chapters, we shall use the formal model given here to precisely describe the 
algorithms as well as to show their correctness. We will formalize our notion of "correctness" 


later in the thesis. 
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Chapter. ¥ ee 
The: General Swrategy 


The goal of this thesis is to design effi cient algorithms which guarantee complete security 
of all information i in the VIM system against loss or corruption ‘because of hardware malfunction. 
In this’ chapter, we discuss the general approach ‘that, we shall take i in formulating these 

procedures. In the next section, we present a failure model of system operation. This model 
- defines the appropriates. context in which to:reason about: the-desigh of-the backup and recovery 
_, algorithms.. In section 3:2,:.we- rise some. fundansental issues that niust be addressed by the 
. backup and recovery system.:.-These issuies.are comcernest witle wirett backup is performed; how 
backup procedures are invoked and ‘how the’ transfer:of infoomation ‘from the maint memory to 
- the backup store is handled by the. backup system. We/shall be considering the problem:of data 
security in. the context ofa single user systern in’ ‘whiek ysonidetermhrate computation is not 
allowed. Section 3.3 gives a high levet design of the betings-and recovery algofithms, We 
_ classify the information found i in the VIM state into two different Sapegories an and discuss how the 
information in each of these categories is viewed by the backup cedures, We also, describe 
the basic operation ‘of the recovery algorithm in this _section. . "Section 3, 4 discusses the 
~~ architectural enhancements that need to be made to the basic vim architecture to efficiently 
support the implementation of these procedures. These cheuemeats « are primarily concerned 
with the physical organization of the backup store. The last section is a summary. of the Chapter. 


3 I Failure Model 


Many of the decisions that are made i in the design of the backup and _Fecovery ‘system 
~~ follow from’ the failure model that i is ‘assumed. A failure model iga a specification of hardware 
~ behaviour characterizing the type of faults expected and the ¢ interaction between failed and non- 
failed components in the machine. Some of the factors which will inflyence the design of the 
backup and recovery algorithms that are described by the failure ‘model include the frequency of 
failures.in the system and the level of hardware elrondeceation capabitity stat is provided. 


VIM is not a fault-tolerant system and, therefore. ‘there will be faults that are, not masked 
which will cause the system to behave erroneously. Iki is unreasonable to expect, however, that 
there will be no fault coverage in the system at all: ‘ike many, “conventional systems, vim is 
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expected to provide enough fault coverage to carrect many common errors arising from minor 
transient faults. Correction of single bit errors in memory, for example, is a feature which is 
found in many commercially available memory. units anid, thus, the services of the recovery 
utility should not be required when such an error is detected. In this thesis, we shall assume that 
the recovery utility i is invoked only when errors cause information found on main memory or 
secondary store to be lost or corrupted. Power outage, short circuits, a malfunctioning disk head 
etc. are some examples of the type of faults which lead to such errors. 


We do not expect that such faults will occur frequently; hardware is assumed to be reliable 
most of the time. We do make the assumption, however, that. invalid information created 
because of an error is detected when it is accessed..For example; if a faulty disk head causes data 
to be written incorrectly onto disk, then when. the data is. read at-some future time, the error will 
be detected. This assumption is important because it:means that any information which the 
backup system observes and copies will either be corrector detected as being erroneous — 
.. invalid:data is never maintained by the backup utility. - 


If the recovery utility i is invoked, it will néed to reconstruct the system state based on the 
information preserved by the backup facility. During this period, another failure may occur; the 
recovery facility must be robust enough to correctly restore the system state even following such 
circumstances. We discuss how this may be achieved later i in the thesis, 


3.2 Fundamental Issues 


The backup system will need to interface with the interpreter and shell to moniter the 
progress of computations in the system. We need to decide, however, when it should actually get 
invoked and by whom. ‘Secondly, once it is invoked, what information should it actually copy to 
the backup store? Thirdly, how should this copy operation be performed ie could normal 
system operation be intermixed with the execution of the backup procedures or must normal 
processing cease while the transfer of data i is taking place? 


The first question was already partially answered in the previous chapter where it was 
mentioned that the semantics of the base language instructions could be suitably altered to 
~ support the backup procedures. Unlike most conventional systems, the backup utility is not 
explicitly invoked by any process or user? it is implicitly activated whenever the appropriate base 


language instruction is fired. In a sense, the “logic” of the backup algorithms is distributed 
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among the. various base language instructions, described. earlier. The question of which: process 
_ activates the backup facility.is not. germane under this design... Noone process is responsible for 
_invoking the entire utility; different portions. of the: -backup .prosedures are activated as 
instructions in an activation are enabled. In this.sense, the backup facility.is more an:extension 
of the interpreter and shell, rather than as a separate program: which is-periodically. invoked 
according to some predetermined policy. VIM offers the opportunity to make the backup ‘facility 
_ More efficient because it is embedded. within, the. interpreter and shell. This organization: will 
_ allow us to design a backup: facility that.can observe, the. progress of computation to a greater 
degree than would otherwise be possible. ; 


The answer to the secOhd question involves detérminitig how much information should be 
preserved and how the remaitider of the systenti staté ‘tan ‘be defived from this'data. While all 
data generated by the system could conceivably be copied onto the backup storage medium, it 
_ Would not be a very practical solution because of the averhead.incurred... Because all instructions 
_ in the base language generate data and update. the system state. danplementation of this stzategy 
would involve modifying eyery base language. instruction to send. the: result of:theis execution to 

backup store. This would clearly result in severe performance degradation. The backup 
algorithms will, therefore, need ta maintain informatio#i aliout theisystent state ini. condensed 
form which the recovery system. can subsequently use. to necoves, shat part of the system state not 
explicitly preserved. As we shall see, most of the. design effort, for, the backup. and. recovery 
system. will be devoted to devising efficient algorithans on ‘ai ain. and. interpret these records. 


. We discuss this i issue in greater detail in the next, section. . 


Because VIM is an applicative system, no data found on the heap, once created can be 
subsequently altered by either the backup system or thé interpreset. “Thus, having’ the backup 
procedures operate concurreritly with normat system Operation! ‘Canriot causé any invariants over 
the data to be violated. 'Moréover, ‘the data copted’ by the backtip’ System will ‘hever be in “an 
inconsistent state when the copy operation is ‘performed’ ‘bectube hb ‘updating of information 
takes place. Our backup ‘procedures can: therefore: be” ‘altowedt to ‘exccuté concurrently with 
“normal system operation’ without the need for any exptictt cotisisténicy chiécks. | 


During the recovery process, no shell commands. are accepted _ the: system. If shell 


there is a caveat to this claim which will be explained in the next chupter 
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commands could be processed concurrently with the recovery process, it may be possible to have 
computations reference data which has still not been restored by the recovery procedures, ..In 
addition, this restriction also simplifies the interface between the recovery procedures and the 
shell by avoiding the need for any synchronization protocols ‘between’ the two processes in 
updating (or deleting) environment entries. When the recovery procedures’ are invoked, they 
make no assumption about the integrity of the data which may stilt be accessible. Thus, the only 
information used in the reconstruction of the state is that found on the backup store. Of course, 
‘it is inefficient to restore the entire state of the system if ‘only: a fraction of it ‘were affected by ¢ an 
error. Significant complexity i is added to the backup and recovery procedures, however, if we 
require ‘the system to support partial recovery. Tt is not clear whether the benefits derived from 

implementing partial recovery outweighs this increased complexity. we shall address this topic 
. again later in the thesis. _ 


oe tiesto Stier ewe 


In the next section, we present the high level. Scien’ of the ae and recovery 
algorithms. The rationale for our design decisions have been ey basedt on the effectiveness 
of these algorithms in addressing ee eee SY See TRS. GS 


33 A High Level Overview of the ices and pecan Factlities 


The design of the backup and recovery facilities are based on one important observation: 

every computation in the system is associated with the evaluation of some shell command input to 

the system. Thus, one immediate solution which presents itself i is to simply record all shell 
commands on the backup state. This is obviously 4 correct solution since the behaviour of the 

system is presumed to be determinate. Reexecuting, inthe proper serial order, the shell 

commands that were input to the system before the failure occured is, therefore, guaranteed to 

yield a correct state. This state will be identical to the. state immediately prior to the failure 

except for the uid's associated with structures and activations. The uid’s chosen during the 

recovery process may not be the same as chosen originally” but because these uid’s are not visible 

_to the programmer, no difference in the two states will be externally discernable. Obviously, 
such a scheme would inflict little degradation to system performance since only the text of the 

shell command need be maintained. On the other hand, recovery would be intolerably slow 


because every shell command is reexecuted from scratch with no information about the results of 


2 Recall from Chupter two that no restrictions are made on how uid’s may be selected 
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_. these commands being. kept on. backup store. . The recovery. ‘system, starting from some initial 
__ Tecovery state, would need to reexecute every shell: cammand inpud to:the system from the start 


of system operation .because.no_information:.ahout ‘the sesult: of any of these commands are 
recorded. Such a maar drawback makes Khis pe unattractive ed all L gegtiaers purposes. 


pee ee lars 


To see what optimizations can be ‘ais ta le taiathdaganieae, let us examine how shell 
commands are used to alter.the system. state. “The. shell cogsmand: of interest .to.ushere is the 


BIND command. The BIND. command. binds a name.tothe resultia£aone computation and:places 


this binding in the user's environment, . The value, hound.4o, tie name represents a long-lived 


_. Value — it survives the computation in which it was created, -The- data seen by the user of the 
_ system are precisely the values bound in his, environment. . Since these values have lifetimes 


greater than the computetions ia which they. weve.defined,.ito would certainly be.a major 
optimization. if. the backup facility maieined these walueson:the:buckup:store. ‘This would 


_,Obviate the need for.the recovery system: 10 -meexeoute: taose commands: whose evaluation 
produced these values.. The backup. facility mast new,in additioa to maintaining a log:of the 
_» @gmamands..input,.to the system, alsa..recond -alli<neme, saiva> bindings. found :in the user 
_ environments. These. bindings cannot be. arbirtarily.chenged teseuse VIM is applicative; thus, 


once a binding is renostiechan, baebas. sons. hechanecdaibte need ares egal reexamine that 
entry in the user environment to check if it has been altered. 


The data found in Via may be classified into two:categories; . quiescent, which corresponds 


__, to the result values of computations associated. sith Alba Commandsthet have-been bound. to a 
_, Name in a user environment, and saanaitional, which eamgepanda 60 those: alues that ane either 


... part of some. active computation. oF Fasult, values of.¢ computation iket have not yet been bound 


to a name in some environment. A computation consists of the collection of activations .andidata 
created during the evaluation of a shell panier: Instructions in — activations produce 


~ transitional data ‘ince ‘this data’ will survive for ‘only 8 s0 Tong, os io computation in which it was 
~ created ‘exists, The value finatly’ produced bya computation will get i bound in in an environment 


qh ae 


anid, as’ ‘result. wilt become quiescent ‘the ‘backup facttity. according t to the scheme presented 


“above: would only, ‘be aware of quiescent data.” Transitional information corresponding to ‘data 
produced during a compiitation ‘would’ not be under the scrutiny “of the backup procedures. 


“When 4 faifure takes place and the system ‘state needs to be ‘prog properly. restored, the ‘Tecovery 


“facility first restores: ‘an Guietceht ‘data ‘Preserved by the ¢ backup facity © ofito o the | new y Tecovery 


we nasties i642 Ty ere als or eee ee eer em OS. 
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state. It must then reexecute those shell commands found-on the oémimand fog which had either 
not yet compieted.or whose result binding coutd not dé revorded*by the backup waa before 
the failure. These shell:commiands will be referred'to a8 Vokettiecenitnnneits: eS 


Having the backup facility record: cali ‘ailment deta i is an . optimization that redistes 
overall recovery time, It does ‘so without: excessive performance ‘dégradataion because the 
backup facility is only invoked<when' an ADDTOBNY instrudtiotl ‘exécutes ‘to’ actually place the 
binding in.the environment: and; moreover, cart perfonie the Gopy of the data in parallef with 
normal system operation. It would be an even greatest aptiinitition if the ‘backup system’ could 
_ help reduce. reexecution time of: those volatile -sliell ‘convmends' fouttd: on the fog by recording 
- information: about those computations which wore‘active at thé-itie’of faiftite. If there are many 
-resource intensive, tinve-consuming activations A 4 eompeataion! den ‘having the backup facility 
ignore the presence of the transitional data: prodwoud if this computtition theans that the time to 
eee Oe See ee eae eee ee ee ee ee 
_ entire computation.’ This:is not very desirable site: the-ee 
executing fora very long period when the failure took iplade< Mabitaining wine record of the 
-. computation on the ‘backup store.-would -sllow: the ‘fecovely: ‘Facility to avoid: needlessly 
ieetecatins tee tees oS pereite iariraineedaname aia before the 
failure. Ce 


: It is reasonable to expect that there will be mamy edniputations:in progress at the time of 
. failure, To tecord the progrets of these computations: thé tiekup Systelt maintains information 
-- about these computations on' a companion Hecate Satie oak We iss sttuctiire of a 
computation sai ag aca aaattslana a) vipa ‘eth oe the next 
| We can now present our intended model of system, 0 p 2 ui ve for. viM, As computations 
complete, causing, values to be bound within some. environs ner nt the, backup facility preserves © 
_ these bindings on the ‘backup orage "megiura. dn addition, there will also be many active 
‘computations ir in progress. The backup, facility maintains int fon matio mn about, these. computations 
as well. This information, embodied wa spmputation, rep cor rf, can can be used by the recovery 
procedures to avoid needless reexecytion of computations tions which. had already. produced. their 
result before the failure, When the recovery system | is invokes i firs restores all quiescent, gata 
~ found-on the backup store. It then uses the computation oan restore the remaining part of 
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the state. The state after recovery is complete will be ¢quivatent to the state which existed prior 
to the failure insofar as the structure and information content of both’ states will be the same. 
The states need not be identical, however, because the ‘id's’associated with activations and 
- structures may be different. The reason why the states‘ would fiot' be identical is because the 
order in which enabled instructions are chosen’for execution may be different during the 
recovery process than before the failure. This does not‘ coripromise the correctness of the 
recovered state’ because of the ‘applicative nature of Vim — no sidé-éffects occur and, thus, no 
explicit ordering on instructiofi execution needs to be adhered ‘to. We illustrate the system 
operation in Fig. 10. ae 


"Failure Detected 


State sl 


S is equivalent to sl Time 
Figure 10: System Operation 


3.4 Architectural Enhancements 

Up to this point, we have only mentioned that the backup store on which backup data is 
kept has the property that information entrusted to it will survive failures of the machine with 
very high probability. The most common type of backup store used is ‘magnetic tape. “The 
~ sequential access nature of tape drives, however, makes it ‘inconvienent to update the 
information found on the tape. " Since the ‘backup facility wil be frequently updating 
‘computation records associated’ with active ‘computations to “reflect the progress of the 
. “computation, using tape as the only backup storage device would be impractical Our design 
- dictates the need od a fail-safe storage device from which information may ‘be easily accessed, 
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updated, and deleted. We call a device which has these properties.a stable storage device. It is 
not difficult to implement such a device on top of non-stable storage devices. Lampson 
[21] gives one implementation of a stable storage device. in. which disk storage is converted in to 
stable storage by maintaining multiple copies of the data on different disks and ensuring that all 
writes to disk are atomic ie, the write either takes place.on both disks or on none. Because both 
disks are guaranteed to have consistent information, data dost because of failure of any one disk 
can be recovered from the other. Advances in VLSI technology have also.made it conceivable to 
consider a hardware implementation of stable storage using, for example, CMOS static RAMS 
and a backup battery supply. Because of the low power consumption of CMOS. chips, 
information on RAM could be retained, despite power failure, using the backup battery supply. 
In this thesis, we shall not be considering implementations of stable storage but will assume that 
such a device is available for use by the backup and recovery utilities. Because of its relatively 
high cost, we shall also assume that stable storage is not very large (certainly much smaller than 
the size of the backup state) and, therefore, in order to guarantee that backup information is not 
susceptible to loss, it will be necessary to have. another backup storage device capabte of holding 
that part of the backup state which cannot be. héld i in, ‘stable storage,. We.assume magnetic tape 
storage is used for this purpose. 


Quiescent data is never updated by the backup procedures and, therefore, can be kept on 
tape. Of course, if the binding is subsequently deleted, the data will have to be removed from 
the backup state as well. A delete record indicating that a value has been removed from the user 
environment can be written onto tape in such situations. ‘The. ‘computation records associated 
with active computations do need to be accessed and constructed relatively frequently. These 
records will, therefore, need to be held on stable storage. In addition, the command log, which 
| contains all shell commands input to the system. whose results have | either not yet been produced 

or have not yet been recorded onto backup store, will alo need 9 be held on stable storage. As 
we ‘shall see, most computation records will be relatively short “lived and, thus, will not occupy 
. stable storage for any significant amount of time, The fi fi nal value of a computation record is 
| quiescent and can be migrated onto tape, allowing the space used, by. the computation record to 
be reclaimed. It is expected that stable storage. will always be able to support all computation 
; records in the system ‘because of their short lifetime. When the recovery system is invoked after 
a failure is detected. it will fi irst read from the tape al the quiescent data and will restore as much 
of the environment image as possible from this data. Volatile shell commands are then executed 
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Quiescient Data 


Command Log me Transitional Data 
Figure 11: High Level Organization of the Backup Store 


from the command log in the order in which they were originally input. The computation 
records found on stable store are used to reduce the overall reexecution time during this phase. 
When this phase is complete, the system can proceed with normal_operation. The high level 
organization of the backup store is ea in Fig. 11. 


We illustrate the organization of the. VIM system. with the aes bees -and-environment in 

Fig. 12. The backup heap is used to hold all transitional data whereas quiescent data is held on 
the backup environment. The backup heap and environment constitute the VIM backup store. 
The Interpreter constructs computation records:on the. backup; heap. duriag normal: processing 
_ and interprets them during recovery. In addition, the intermediate results ofa computation are 
also stored on the backup heap by the. interpreter, <Name.Value>: bindings are placed.on. the 
backup environment by the Shel! whieh also builds:the comnvand:log found:on the backup heap. 
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— — __ flow of information during recovery 


Slow of information during normal processing Activation 


Tnatstiction 


Figure 12: Abstract Architecture of the Vim System with Backup Store 


3.5 Summary 


In this chapter, we have presented a high levet strategy for’ the backup and recovery 
algorithms for the VIM system. Our main observation about system Dehaviour was that all active 
computation in the system is associated with the evatuation of' some shell command. The first 
solution proposed involved simply storing the log of all'shelt commands, reexccuting them from 


the beginning if a failure occured. While correct. because VIM is a determinate system, this 
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solution has the drawback of a very slow recovery time. A major optimization to this solution is 
to record all quiescent data ie data bound in some user environment. A further optimization, 
intended to reduce the overall recovery time in reexecuting volatile shell commands is to have 
the backup facility maintain some measure of information about all active computations. The 
recovery facility uses this information to avoid needless recomputation. Once this reexecution 
phase is complete, the state of the system is properly restored. During this reexecution phase, 
the order in which instructions are executed may be different from the original execution 
sequence. This may lead to different uid’s being assigned to different structures but the overall 
structure of the heap and activations component remain identical. The reason why the order of 
instruction execution is not important during the recovery process is because VIM is an 
applicative system. 


We also introduced the notion of stable storage in this chapter. Information about active 
computations will need to be frequently recorded by the backup system. A backup storage 
device on which data can be easily accessed and added is required to support these computation 
records. While quiescent data can be copied onto tape storage, computation records need to be 
maintained on stable store. | 


In the next chapter, we present the detailed organization of a computation record and 
discuss how the backup system monitors the progress of computation. As we noted earlier in this 
chapter, the logic of the backup procedures is actually distributed among certain base language 
instructions. We present a formal model of the VIM system supporting the backup and recovery 
procedures and argue that the information embodied in the computation records is consistent 
with the actual system state being represented. | 
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Chapter Four 


Constructing Computation Records 


A major aspect of the backup and. recovery:.algorithms for VIM concerns the construction 

__ of computation records, .Recall from the last chapter that:a computation record is used to record 

_ information about currently. executing computations::..In: this chapter, we shall be primarily 

__ interested in how computation records maybe constructed andymiaintained. In Section 4.1, we 

_. present the abstract, representation of computation records. The avain component.in the! record 

_ is known as an activation deseriptor entry which embodies: state information about an individual 

_ activation. In order to cpastruct 2 computation record, changes'¢o the ‘operational behaviour of 

_ the base language instructions givea in. Chapter Two will ‘be necessary. Section 4.2 discusses 

_ these changes as well as changes: necessary to the shell and intespreter. In section 4.5, we present 

_ the altered operation. of the base language insteuctions in: terms of an abstract operational ttodel, 

MR, which is an extension. of model Mi presented -in; Chaptertwo. There: are several major 

optimizations. which. canbe made in managing ae ‘peoords, These eee are 
. also formalized in this section. 


4.1 The Computation Record 


In Chapter three, we argued that the backup system should record the progress of active 
' ‘computation in the system to help reduce recovery time. A _gomputation , record ds. an 
~ information structure constructed by the backup system for this Purpose, - Our focus in this 
" section will be on determining how much information should be kept on the computation record 
to allow the recovery procedures to restore the system to its state prior t to the failure. One simple 
‘Scheme: would be to Periodically checkpoint all activations created by, a computation. To 
checkpoint an activation means recording the state of all instructions which have not yet 
‘executed in that activation at the time of the checkpoint. ‘The state of an instruction consists of 
its opcode, destination fist, operand and signal count, as well as the value of its ‘operands’, This 
approach: would be very similar to that taken in many other Parallel computer systems where a 
“recovery [ point representing the state of one of possibly many concurrently executing processes is 


3 Han opcrand is a complex structure. Uhis means recording.al. substructures referenced from the top-level structure 
as well. . 


* that each function: can be treated as a constant applicative fo form 


ay 
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periodically taken by the systems’. backup facility; :In‘our system, the recovery procedures would 
only need to find all enabled instructions in Ee ee, renee to begin the reexecution 
phase. ad, ean ae. : je ee as 


Periodically recording the state of all activations created bya compatation is simple idea 
but has two major drawbacks which does not makexit a fensible sdlution-for our purposes. ' First, 


. cheekpointing all. activations ix: a computation: will probably ‘be ud costly task Because tite size of 


activations can be very: big. Secondly,:in ofder:s0: guarantee ‘that’ a Corisistent ‘image Of the 
computation is maintained on the backup utility, we would’ have: to “disallow any enabled 
instruction within any activation in that computasion frompexecuting while the checkpoint of that 
activation is being: performed. To see why this iis thie‘case, coridifer two activations, aand'B in 
the same computation where a-has called B: If f'is allowedt0 exegete-while'a checkpoint of a is 


- being made, thea £ may.retunr its result:to’'a and then exeoute ® RELEASE operation. “If the 


image of a on backup: state does ‘not reflect’: the renien “velue’ sent bya, and’ was’ not 


_checkpointed before the RELEASE operation executed, ' te computation ‘record would ‘represent 
_ an incorrect:state: Upon recovery, thers: would ‘he ne way w tebover the retatn result valud Of B 


without reexecuting a. This is precisely a manifestation of theypdeblems enéoutitered ‘ini other 
concurrent systems that use recovery points to guarantee data gia 


A more clever approach to recording state information about activations takes es advantage of 
the applicative programming model VIM uses, “A disti ct ve feature of: an 1 applicative language is 
be orm af, . A caf consists of constants 
combined by function composition and ‘application, In conyentional ‘programming languages 
such as Pascal or Fortran, a function cannot be treated a as a constant because its evaluation may 
cause side-effects to occur in the Program, In Vin, having all functions be simply constants 
means that the behaviour of the function can be determined by just knowing i its inputs. In the 
base language, an activation is the application of a function to some input. Becayse functions are 
caf's, we can embody an activation on the ‘backup Sate by recording the function closure, its 


inputs and return link. Under this scheme, the recovery system would need to only APPLY the 


closure to the argument list to construct the corresponding activation being represented. An 
important advantage of this proposal over ‘the checkpointing one is that no executing code is 
maintained on backup store. Because all data is immutable, the transfer operation of the data 
from main memory to backup store can: proceed. in:paraliel with the cxecution of any activations 
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. which operate on this data. Moreover, the amount of information which needs to: be copied is 
_ also greatly reduced since no data.created by instructions within these instructions are preserved. 
_ Such data would be recovered when the activation is reexecuted. 


A natural representation for a computation record in this scheme is as a directed tree in 
which nodes represent activations and edges indicate caller/callee relationships between pairs of 
activations. This tree is known as the computation tree for the computation. We illustrate this 
representation in Fig. 13. 


2. meted ara mee 0 ea 


Figure 13: Representation of a Computation Record 


The root of a computation record represents the initial activation constructed by the Translate 
function of the shell. Every node in the computation tree is labeled with the uid of its 
corresponding activation. If (sé) is a member of E.,. the set of edges in a computation tree c, then 
activation ¢ is instantiated from activation s. Each computation has a unique computation tree. 


A node in a computation tree. is called an. activation descriptor entry. An activation 
descriptor contains the necessary information about an activation needed to restore the state of 
the activation. The representation of a computation record given above is simple but certainly 


does not help much to alleviate recovery time for transitional data, This.is because computation 
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trees may become very large for long running computations. Reducing the size of the 
computation tree would speed up the recovery procéss. The information in an activation 
descriptor entry in this scheme contains the closure and argument list of that activation. During 
recovery, however, every activation represented by an activation descriptor entry in the backup 
state would be reexecuted. The time to ‘reexecute all these activations would result in an 
unacceptably high recovery time. Clearly, what i is needled is a mechanism. to record results of 
activations as well as their instantiations. Thus, when a result of an activation is known, it 
replaces that activation in the computation tree. When this value is encountered by the recovery 
procedures, it is sent directly to the destination addresses, ‘eliminating the need to reexecute any 
activation in the subtree rooted at the node containing the result. In this way, we can imagine 
the computation tree growing and shrinking in response. to the instantiation and completion of 
function activations. This process is shown in Fig, 14. 


{ 
| 
| 
, | 
oe 
VY 
Suterees rooted at a2, a3, and a4 


Figure 14: Dynamics of a Computation Tree 
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When an activation is instantiated, a new descriptor efitty is placed in the computation tree 

and an edge, is added se the caller to this new. en. When. the Regult of an setiyation becomes 

. entries are then removed. There g are two o feauures of ro seioe that slept it — apa 
data backup. strategies found in ‘conventional systems, . The ; first is that. the: updating ;of state 
information i in our scheme is dependent totally, on, | REQREAM. behavior. As.we had mentioned in 
the last chapter, typical, backup strategies use a.prede : policy to determine when. the 


CEES 23: 


checkpointing ds to. be done, The second, and more: important, difference. is that hecause. the 
construction of the computation tree takes advantage of the applicative programming model, the 
computation: tree canbe “pruried” whenever 2 teeutt’UF arr bctivation ‘becdmes Khown. In a 
~ language which permits siee-effects‘arid Sharitig’ of tio 4ocat’ sone we would hot be able to 
enna the a oes nd! St etnies iinet. y 


itn now remains 9 show exactly how the pean ‘pall md bie lengua semantics 
need to be modified to support the construction of the ords. ..We examine.the — 


rhs DEL 


| structure of an activation descriptor entry in greater. ih eae neni sertion. 
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4.2 The Activation Descriptor Entry . | 
7 We nid mentioned i in the last section that an vativasca tone nine should contain eoouch 
information so that the. recovery procedures could restore the,.state Of the activation, ...We 
observed that if the function Closure and argument, ist.of the activation, were preserved, then the 
_Tecovery procedures need only apply. the, closure, to the argument; ilies the return link, to 
_ estore the activation state, é 


The recovery process in this proposal is ‘straightforward. “att detivatton descriptor entries 
- containing the function closiire, argument recortt atid “fétiimn Tink ‘Gan’ Have the function 
' application take place in parallel: Whenever’ an ‘apply operation 6 to be executed’ during the 
recovery phase, a check is made to see if the furiction H&S affeddy’ been ittantiated: That is, all 
APPLY instructions during the recovery. phase..check, to sge.if an activation, descriptor already 
_ exists for the activation they are to initiate. If one exists, we.can effeetively, ignore the instruction 
since the result of the application, is already known. If no, such descriptor exists, we perform the 
application. Result values found on an activation descriptor entry are used to prevent initiation 
of an activation, When a value is found in an ADE, it,can be sent directly to the destination 
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address specified in its return link’. 


In a system in which errors requiring intervention of recovery procedures are assumed to 
be relatively infrequent, wé may find the cdst of even maintaining function closures and 
argument records too expensive. As we explain below, the ‘main reason for needing the closure 
of the activation on the backup store ‘is if we wish’ to’ ‘have all’ activation descriptor entries 
-evaluated in parallel. If we are willing to tolerate longer recovery time, we can ‘signficantly 
reduce the amount of information which needs'to be held on ‘thé activation entries by 
eliminating the need to hold even the function closure of argument record on backups store, 


Instead of Havin al activations ‘initiated, in. parallel, we can. have the computation 
reexecuted from the initial activation descriptor in, the. computation tree, Whenever..a-new 
activation is about to be initiated, the recovery. procedure. first, examines. the corresponding 
activation descriptor entry for that activation (remember that there i isa unique computation tree 
for every. computation). If that entry contains'a result thien that valve i is ‘used directly and the 
new activation is not initiated.’ If. on the other hand, nd result value is | found i in the descriptor, a 
new activation is constricted and’ processing proceeds as hortial” “No function closure or 
argument record needs to be maintained in this scheme because the computation is reevaluated 
from its initial activation — no parallel invocation of activations within the computation takes 
"place. While the time to festore a cortiputation is greater than ‘if function closures were 
maintained in the backup state, it is bourided bythe tiie the system’ Wold have taken to have 
processed this computation under normat circumstances. ‘If fonction ‘closures and ‘argument list 
‘of activations were maintained, then the recovery system ‘could exploit more parallelism than 
what was available during the original evaluation of the computation precisely because all 
activation descriptor entires.in the computation, record.could. be ¢valyated concurrently. It is 
important to keep in mind, however, that even if this extra informtion is not kept on the 
activation descriptors, the reexecution of the computation, would still exhibit: as much 
| concurrency as it would have under normal conditions, 


The information held pies an activation diaapebeats musta ayo the Peeowely lariat 


eek. 


descriptor. The first form is for those activations ‘whose results‘ were ‘recorded by the nveesup 


4We are assuming that uid’s of activations are preserved in the backup slate and are used during the recovery phase 
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» facility. Hf an ADE for an activation a contains a valiré: ‘then this’ value represents the result of a. 

The second form of an“ADE is used When-the resi’ UP an aéVation Has not yet' been recorded 
_ by the backup facility. “BY tis Case, the’ ADE Gintitiis ‘the Kdgies(b’ alt activations: that’ were 
initiated from: abeford the Rallufé octa red -DunAg ebay" Will be teexéctited Recalf that 
— inthe ln tree —— wetted!” a 
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__We represen an edge i sctvatpn 2m deecipor OR SARIN le al? caine et 

_,, Represents the ‘offset, in the activation FMS of 2 function aRplication., o, inaTUsion. 

___instantiates th ‘the new activation and w whe her re uid 1 Te ents she uid 98. the activation, dese 
"associated with the called J activation. | The off a somponent voigvely, identifies, the actix 
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being initiated. When an ‘application instruction is encountered during recovery, the sc vation 
oo escripwne corresponding whe acti vaaioii ‘to be Hinedaiitinted Wetamined Tf a vate is’ present in 
», this ADS, itcan:be sent directly a ueb deiscteatnon tmerdaeiontslbtine iperitit: The ofiser Heid is 
+ used torlocate the ADE bf the aotivation toe tatneanie! Whe reasdit Wty we niéed' the offser 
_ field atalt is because the order ix: which Jestunt ehetutePAi ring teddvery may Tot be the 
© same ws: the: order-de which thay: sere drighhallyeneeatbd:! OF stgiiettial languages: eVery 
function application és ordered: with respeotite-every emer ap hcatibh’” Réeiécutin ofa given 
> sectivation will aobchange this*ordering. \th'a odricuttine spatdad Suicll dé’ VINE WHete does 'tiot exist 
_vaniy'a@ prion ondering! on intrucsionencdution.: ‘Fiass hea beRh “niithber: offser:“Of' the 
; function application operator Lei; APREY: eempeaiavalan becca a head 
plane coe saat arene te ery ee 1D i an 


| The scheme we have ‘given above ‘equires ‘ttle, imervemion, by the ‘backup facility 
| Function “application is noted by adding a new, 3) vation. Seseriptor | to the appropriate - 
computation tree. When the result of an actiyation is kn known, it ifeplaces. the descriptor entry for 
that activation on the backup state. We do not mainian, argument, records and closures, of 
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activations, choosing instead to reexecute the computation.from the beginning, only avoiding 
. reexecution of activations whose results are already. knowa. While recovery time in this proposal 

_is greater than the one in which closures and argument zegords are maintained, there is a 
substantial reduction in the computational resources, requised by the backup facility. As we have 
mentioned previously, efficient, implemention. of this strategy will require alteration of some of 


the base language instructions. A formal definition of these operators is given in Section 4.5. 


4.3 Early Completion Structures . 


The preceeding sections have presented: the general framework and rationale upon which 
computation records can be organized. While : sufficient for ‘most cases, there are certain 
program. structures for which our design j is still. inadequate. “Fhe first type of program structure 
not properly addressed in our presentation is the early completion structure. By itself, an early 
completion structure does not add useful information bo the backup state since it only indicates 
~ that’ an activation has been initiated to produce the desired value. Copying a an early completion 

‘structure onto the backup’ store would not allow the recovery system to restore, the proper ‘state 
unless the ‘activation responsible for producing the Value which is to replace that structure is also 
‘copied. Tne Repu tot a desirable situation to have | to eal with. — 


For our purposes, |.a. abies (and more stiles Sele 9 4s to avoid: copying. early 
. completion elements until alk the. early, con a fields in thesgnactuse become sef. ‘When a 
__ Structure which contains early. complation; fields. 0 he. copied onto backup store, théseierfields 
_-are.labeled with a special flag indicating that the enasaining structure is to: be eventually copied. 
. When a SET instruction. eacountess. such 3.figld; it: checks: to.see whether any: other: early 
: compietion elements exist in.the. structure; if so,:negopy operatinnis perfarmed; otherwise, the 
_ Structure is copied onto, the backup. store, The ADE which: is-td: reference: this structure :will 
initially have its value field reference a structure witha special.value, netsapied. When all fields 
__ in the structure are known, this reference gets neplaced:with:.thecsefergnce:to. the fulty defined 
structure. If the recovery routines encoynter.a structure with @ value Anicopied, it is ireated: as 
not being defined and is ignored during the reexecution process. The Structure containing the 


early completion clement being set may be a ‘component of a larger structure which also needs to 
be copied onto the backup Store. If this structure becomes fully defined as a result of executing 
‘this instruction, then it too will’ gel copied onto the backup si siore. We illustrate the effect of the 
‘SET operator on the backup store in Fig. 16. 
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S is fully defined by SET operations and is transferred to backup store. 


Figure 16: The Effect of the set Operator on Backup. Store 


4.4 Further Enhancements 


There are two other program structures whose behaviour cannot be efficiently captured by 
the backup facility by just modifying the semantics of the APPLY and RETURN operators. The 
first is the tail recursive program: expressed. using the TAILAPPLY operator.” The second’ class of 
‘programs not handled by our system are those involving thé production of- streams implemented 
using the SETSUSP and STREAMTAIL instructions, “Both theve! dlaises of programs use special 
function. application and signalling operations which tequiré-more’sophisticated ‘algorithms than 
those presented above.’.in the next two.subsections we'discuss how’ the backup system should be 
augmented to.handie tail recursive ‘activations : a ene ee ‘of stream 
structures, 
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. 4.4.1 Tail-Recursion 


Recall that tail recursion is used to implement iteration in the base language. The key 
feature of tail recursive activations is that they need hot persist until the recursive call completes 
because the return link is provided as the third operand to the TAILAPPLY instruction. In our 
current design of the backup system, if the TAILAPPLY operator was treated as being identical to 
the APPLY instruction, then every tail-recursive activation..would cause a new activation 
descriptor entry to be constructed. The structure of the associated computation tree would 
contain a long chain of ADE’s with only the last ADE in the chain having the relevant result 
value. The backup system can optimize the construction of ADE's when tail recursion is 
involved by reusing the same ADE for tail recursive calls instead of building new. ones for each 
new tail recursive application. An important observation concefning tail recursion is that tail 
recursive activations differ from each other only in their argument records. All activations 
initiated from a tail recursive call use the same function closure and return link. Each activation 
serves only to construct a new argument record for the succeeding one to use. In fact, because 
activations in which the TAILAPPLY operator executes-do not retum a result value, there is no 
RETURN instruction which is executed. It should be clear that this behaviour is not well 

“supported by our backup algorithms which very much depend on results of activations being 
recorded on backup store in order to help reduce recovery time of, volatile commands, The 
reason for this incompatability i is the fact that no tail- recursive activation except the last returns a 
result, making any intermediate tail recursive activation descriptor entries essentially useless. 


We introduce a new type of inact dees ee al recursive: activations which 
includes the argument record of the activation. _Whes:.a.funaction is instantiated by an APPLY 
instruction, an activation descriptor is constructed for:it with type. appty. If this function was tail 
recursive, then during the evaluation of this function a, TAILAPPLY ‘instruction may execute. 
Execution of this instruction, while causing a new. activation to.be-added to the set of activations 
in the system, does not necessitate a new activation. descriptor tobe coastructed as well. Instead, 
we change the activation descriptor of the current activation to type tailapply. The argument 
record passed as the second operand to the TAILAPPLY instruction is recorded in this activation 
descriptor. In addition, all edges emanating from this ADE are removed. The old state of the 
activation descriptor is thus replaced to reflect the new activation. Other function applications 
that take place in the activation are recorded in the tailapply ADE as was donc in the apply 


ADE. Subsequent tail recursive calls in this activation will cause the same effect as took place 
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initially: the old argument record is replaced with the argument record of the new activation, and 


the edges emanating from the ADE are removed. 


The inclusion of the argument record in the descriptor allows the recovery system to avoid 
reexecution of all the tail recursive calls leading up to fre: ‘one Tepresented on backup store. 
Since the closure and return link ‘are the same, keeping the aigummem cord in the ADE makes it 
unnecessary to reexecute any of the prior tail recursive activations originally executed from the 
initial APPLY. The représentation of tail recursive activations we have chosen has two beneficial 
aspects. First, the depth of the computation tree is notinereased for every tail Tecursive call since 
the 1iéw' ADE can replace the ADE of the calling activation. This is because. tail recursive 
activations send their result directly to the address specified j in their third operand, the calling 
activation does not receive the result of the callee. Secondly, by storing the argument record on 
backup store, reexecution can begin by applying the function to this argument record and the 
return link sigs by the APPLY instruction which initially instantiated this function. 


In Fig. U1 we ‘cow some = aiene in the transformation of a computation tree which 
embodies the evaluation of the following function to illustrate the process described above: 


Function Example (/: Function, n: /nteger returns Integer) 


Function: Failexample(m,n : Integer, f:Functioa returns Integer) 
ifm>n 
_ theam 
else Tailexampla f: (m), n) 
endfun 


lagi a nd) 
endian. 


4.4.2 Stream Structures 

Our basic approach to-recording the progress of computations ts-atso not well suited for 
expressing the behaviour of computations involving the production of stream structures. Recall 
from Chapter Two that streams are produced by tail recursive functions in a demand driven 
fashion. The unique instruction in a stream producer which 1 allows | the, lay, evaluation of a 
stream is the suspension operator. The backup and recovery algorithms as currently. defined. are 
not capable of modeling the kind of program behaviour exhibited by stream producers for 


reasons discussed below. 
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Steps in the computation of TailExample, with initial arguments: m = 1 n= 1 and f(x) =x +1. 


Step 1 


Lee [owl 


after Tallexample instantiated. 


after f instantiated 


Computation tree rooted at f's ADE. 


_ Tail Recursive call reuses same ADE. 


Final value of Fanction call is 2. - 


Figure 17:| Handling Taif Recursion 
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44.2.1 Rationale — -_ 

To see why our current method is insufficient, consider the structure of the computation 
tree produced by the backup algorithm (as currently defined) forastream producing function. 
Since such a function is tail recursive, its associated activation ‘would ‘be represented by a 
tailapply ADE. The.return link in a stream producer is used to connect together successive 
_ elements in a stream. When. a new activation of a ‘stream’ pfoducer is initiated, the return link 
_ which is passed to this new activation is the uid of the last stream element. Thus, when the new 
‘stream element is produced, the field previously containing the-sspension in the last stream 

element would now reference this new element. ‘Fhe new element,’ in tum, would either be a 
record whose second field is a suspension to the STREAMTAIL instruction in the current 
activation or the value null denoting the empty stream, 


Now, consider the behaviour of the computation tree if the STREAMTAIL instruction were 
_ to be treated as being identical to. the TAILAPPLY operator. Under this assumption; our backup 
algorithm, would preserve the argument record for each aetivation of the stream producer 
function initiated, in accordance with the description of tall recursion given above. Notice that 
because a stream activation only executes a RETURN. when no mote tail recursive calls are 
necessary, the only result value that would: be: preserved on the: backup ‘store would be the last 
stream element produced. Intermediate elements which are constructed using the SET and 
SETSUSP operators would not be maintained on backup store. Moreover, recording only the 
“argument record of the tail recursive activation for a stream producer would not be sufficient to 
restore the rest of the stream because the return link for each activation is. different, Recall from 
Chapter two that the retum link passed to an ‘activation of a stream producer is actually the 
second field of the record representing the last stream element created by. this producer. Thus, 
the return link of each call to the stream producer would be different. 


This analysis indicates that the current design of the backup and recovery algorithms suffer 
from two. drawbacks with respect to the handling of streams. “First, because tail recursive 
activations associated with a stream producer differ from each other in more than just their 
argument records, we need to maintain more information about the activation on backup store. 
The extra information which needs to be recorded must obviously. include the new stream 
~ element produced. The second drawback is the inability of the, backup algorithms to 
incrementally construct a data structure on the backup store. When a stream element is created. 
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it does not define the entire stream but represents only one element in the stream. "Because 
streams are created in a demand driven manner, whenever a new. stream element is created, there 
is also an activation associated with it whose state. is relevant to the backup system. The 
suspension signals an instruction in this activation to initiate production of the next stream 
element. Of most importance to the backup system is the argument record held by the 
STREAMTAIL instruction. which instantiates the next stream activation. The backup system must 
record this information if it is to properly restore the state of:the system. If the argument record 
is not copied, then there would be no way for the recovery system to generate any further stream 
elements beyond that which has been copied -onto the backup store. We discuss the 
ramifications of this requirement below. 


The instruction responsible for setting the suspension in the stream is the SETSUSP 
instruction. The argument to SETSUSP is the record. representing the new stream element. We 
_ see that one means of noting the production of new stream elements, therefore, is to alter the 
behaviour of the SETSUSP instruction. The SETSUSP instruction, in addition to setting a 
suspension in the new stream element, also initiates the transfer of this stream element onto the 
backup store. Of course, the value of the stream may-be an early completion structure in which 
case it will be the responsibility of the SET instruction:to perform the actual transfer, 


The instruction responsible for initiating a new activation of the stream producer i is the 
STREAMTAIL instruction. The main operand to this instruction of i interest to us is the argument 
record that is used to initiate the new activation. Recording the argument record serves a 
different purpose from its use in normal tail recursive activations. For streams, recording, the 

argument record of the STREAMTAIL operator is essential to restoring the state of the stream 
producer activation to allow further generation of stream elements after the the recovery 
procedures complete. 


The advantage in altering the behaviour of the SETSUSP instruction. to initiate the copying 
of the stream element instead of the STREAMTAIL instruction is that the transfer of the stream 
element can take place before a demand is made for the next element. If we choose to record the 

creation of stream elements by making the STREAMTAIL instruction copy its return link structure, 
~ we would need to wait for the next demand to be made (since that it is when the STREAMTAIL 


instruction fires) before the copy operation of the current stream element can be started. 
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Because stream elements are produced in'a demarid driveri fashion, if the evaluation of a 
bind expression yields a stream, the value field in name, value> pair bound in the backup 
environment will contain a single element initially, namely the first element in the stream. As 
more elements of the stream are produced, they are added « onto we backup . image and are 
considered as part of the silanes in the backup. cavifonmnent: 


4.4.2.2 lnnpletaestation 
To monitor a stream producer, we introduce a flew type of activation descriptor called a 
stream ADE. A stream ADE is-siniilar to a tail descriptor in that both maintain 


information about a function activation other than j its retum value. The stream ADE, 
however, in addition to containing the argument nigotd for the next stream activation to be 
initiated, also contains the stream element result of its associated stream producer activation. 
These stream elements are linked together on the backup heap. “During the recovery process, the 
backup. stream image is first restored. The recovery system ther ponstructs a skeleton of the 
activation of the stream producer. This sketetonis used to infttate production of the next stream 
element when the next demand is made. The only instruction that can be enabled in this 
_ activation. is the STREAMTAIL operator whose argument record is taken from the backup store 
and whose return link i is the address of the last stream element. The suspension field in this 
element is set to the address of the STREAMTAIL instruction. The reason for storing the 
argument record is. 0 ‘Set-up the skeleton activation to ‘Support the demand driven execution 
mechanism: for streams. When the recovery procedure completes, a subset of the stream image 
recorded on backup store will be restored. Let <%, reap a Syé thé stfeam elements recorded on 
backup store. Then the recovery system restores the first y] ‘elements, a < n, where xis is the 
” greatest element for which the argument record ‘heeded 18" ‘Obie ule dit afeam élement has 

‘been preservéd. A skéleton ‘activation is: construed” t8 sl le je dlement | ‘when ‘the 
~ demand for it is made. Duritig the construction of thie értearti On baEKUB store, argument records 
"may be removed from: the strean image wien ak ie wal not be needed 


during the: recovery process, Pung! 


When the suspension field i in the Jest anes eae buku image.is ected aie 
recovery, the STREAMTAIL instruction in. the skeleton activation would fire, initiating the. next 
activation of the eaaced to aes the Jt Ba oe We illustrate this os in is 18. . 


: “oN ats 


Tos summarize, male al the ihiet structures we hive examined. ihere: are two operators 
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F ls the closure of the stream producer function, = 


Figure 18: Reconstruction of a Stream Structure 


- which are responsible for maintaining a consistent, image. nor stream. The SEISUSP operator is 
responsible for initiating the transfer of the EW stream. element QAto. the backup store.. The link 
field of the stream elements. i in the backup image; is updated by.the. STREAMTAIL operator when 
it executes. The STREAMTAIL instruction is also. responsible for-copying the argusaent record. to 
| the backup store. The backup system should treat the argument. record. , passed. to. the 
STREAMTAIL instruction in an activation and the stream element created within that activation 
“‘gollectively to ensure that a correct ‘stream’ inmage’ is ‘preter “the implementation of this 
value, csicapasii record ts discussed fn the next section. EEGs . , 


In the | next section, we roniealize the ¢ backup algorithms outlined milena above. Our 
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formal model is an extension of the one given in Chapter two‘and mainly involves alteting the 
definitions of those base language instructions responsible for the creation and updating of 
ADEs on the backup store. 


4.5 A Formal Model of Backup and Recovery 


Beyond the need for modifiying the behaviour of some of the base language instructions, a 
formal model of VIM augmented with the backup and recovery algorithms must also have some 
concept of failure. A failure should be that special state which ‘causes the system to invoke the 
recovery procedures. The modified operation of the base lapguageénstractions differ'from their 
counterparts in Chapter two in that their execution results in 4 pew backup State as wel asina 
new VIM state being constructed. 


In the following presentation, we shall be using the same notation as in Chapter two, 


within: Poly ¥e 


45.1 The Backup State 
Formally, the VIM system is now treated as a sah il 


VIM =  <Shell nterp BackupState VimState> where 
VimState = = <Act X H XHS x. Eav> u fated}. 


es ee = <Log X sical x BEm> 


- imState. atical ap shee defiatons in. model 

- Mi. ‘Notice that, the VimState in n addition 10 shaving the same components..aa. in. MIL also 
contains the special value, failed. A failure in the system is modeled by having the VimSsate 
take on the value failed. All information found i in the current HigState is “lost;’ if the ViraState 
has the failed value. The domain BackupState is defined as a thiee-tuple where the first 
component in the tuple, Log represents the command Lag of aiPtdlatilé Shell coimttiarids®, the 
second component, BHeap. denotes the set of structure Yalyes, sopicd, by the backup. progedures, 

| and the third component, BEnv contains all ¢name, value> bindings preserved by the backup 
utility. These values constitute the quiescent data in the sysicm: The ‘domain equation for BEny 
is the same as that for the environment component in the VIM state, namely, . 


* SRecall that volatile commands are those commands whose results have either not been produced or have not been 
copied onto the duckup store. 
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BEny = Name —(U,, U Scalar) 


The command log, as was described in Chapter three, is used to hold the record of all currently 
volatile Shell commands input to the system. By safely recording these commands, we are 
guaranteed of being able to restore the correct system state. The Logi is a. two-tuple, consisting of 
a function mapping from natural numbers to log entries and a size € component indicating the size 
of the log. New log entries are appended to the end of the log. . 


Log = <N-~ LogEntry> XN 
LogEntry = <Command X U,> 
U, = the set of uid’s used for computation records, | 


As new Shell commands are input to the system, the text of the command is copied by the 
backup procedures onto the log. This’ text corresponds to the Command component of the 
Logentry. The second component in a log entry is a reference to the computation tree. associated 
with this computation. This somipuaton tree will reside on the ‘backup heap. 


Every element on the backup heap, BHeap, has. San. associated nid.. There are three types of 
elements on the heap: structures which are normal VIM aucune discussed previously, 
activation descriptor entries, and stream coordifiator fecords ‘that’‘are used tO package 
information about a stream activation. We discussuthe,r9le.ofithe stream. coordinator.record in 
greater detail when presenting the operation of the suspension operator later in this chapter. 
Every ADE on the backup heap will either be refereh ec by ‘ante bther ADEin in the computation 
tree or wilt be referenced from a command tog entry fri it is thie Initial ADE in the computation 
"tree. 

BHeap = (Uy U Ug) — (ST U Ade U re a 


StreamRec = <Val.x:Arg X Link> | 

“Ade = <U, X AdcEntry X AdeType x Result> 
Val, Arg = U,, U Scalar U undef | 
Link = U, U undef 


AdeEntry = (N — U,, U empty 
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AdeType = {apply,tailapply, stream, value} 
Result = (U;, U Scalar U unde})) 


An activation descriptor entry is a structure of four components. The first component is 
the uid of the activation being represented. As we show below;‘this.field is ysed to identify the 
activation descriptor so that the result of the activation can be properly forwarded to the ADE 
when it becomes known. The second component; the AdeEniy, is #‘furiction mapping from 
natural numbers to backup uids. . If there are no entries in the AdeEnury, this component has 
value empty. The domain:of the AdeEntry function fs the set of all-instruction humbers in the 
corresponding activation which: are either APPLY, TAILAPPLY, of STREAMTAIL opefations. ‘The 
range denotes the uid’s of the ADE's in the BHeap corresponding to'these activations. Thus, if / 
was the instruction number in some activation a corresponding to’att APPLY instruction, then 
AdeEntry(j) would be the uid of the ADE associated with the activation created by this APPLY 
instruction. Because the computation tree is pruned whenever a tesiilt’ of an activation is 
recorded, activation descriptor entries: will: have their d@eEniry field set to’ the value empty 
indicating that there are no subordinate ADE’s of thigattivdtion and that the result of this 
activation has already been recorded. The third comporient in’the ADE contains the type of the 
descriptor. There are at least two types of ADE'S: ‘appty HDE’s representing activations for 
which a result is not yet known; and value ADE’s which contain. the result of the activation. In 
addition to these two types of descriptors, there are. also, special, descriptors for. tail recursive 
activations and stream producers which we described i in the Previous sections. The. fourth field 
represents the ‘result of the activation. It can either be a scalar ¢ or. a uid. which references the 
structure on the backup heap. All structures are associated with only one uid. Thus, the uid’s 
used to reference structures on the backup heap are.the samé..as: those ‘used to reference 
structures on the VIM heap. We shall use dot notation to refer to campanents of an, activation 
descriptor. | | _ 


When an ADE is initially constructed, there will be‘no: value to place: in its result field. 
Thus, this component is initially set to undef. When a result value is subsequently produced, it 


will replace the undcfined element. 
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4.5.2 Early Completion 


Early completion structures are represented in MR as follows: 
ECQ = 9(ECE) 
ECE = <U,, X N> U {back} 


back is a special flag which indicates that this early campletion structure is part of a structure 
which needs to be placed on the backup heap. This flag is.placed in the queue by the Copy 
function. We present the definition of this function below. When the SET operator replaces an 
early completion. structure. containing this flag with a value, it will check if the structure 
containing this field can be copied by determining if there are. any more early completion 
elements in the structure, 


4.5.3 Auxiliary Functions . 

_ As was the case with the heap in Ml, we have two: auxiliery functions defined on the 
backup heap, AddBHeap and RemoveBHeap, which add and. remove. an element from the 
backup heap respectively. The definitions are omitted here but-the reader may simply substitute 
BHeap for H in the definitions given for AddHeap.and RemoveHegp in Chapter two. 


There are also two functions defined on the command log, AddLog and RemoveLog. 
AddLog adds a new log entry to the end of the log and RemoveLog entry removes a defined entry 
on the log. In addition, we also define two fanctions over t AdeEntries to ‘replace and remove 
elements from a given AdeEntry. 


AddLog:. Leg X Legkatey -+ Log 
Function AddLog( Log, Logentry) 


let <LogVal, size> = Log 
LogVal(m).= Legvakm) if m * size+1.. 
= Logentry if m = size + 1, 

size+1 , 

in 
<LogVal'’, size+ > 

endict 

endfun 


Se EERE REE RENIEBE 
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RemoveLog: Log X N — Log 
Function RemoveLog (Log, n) 

let Log Val, size = Log 

LogVal{m) = tates n 
= undefifm =n 
in 
<LogVal", size 

endlet 
endfun 
NewAdeEntry. AdeEntry x U, X N—» AdeEatry 
Function NewAdeEntry AdeEntry,u, n) 


let AdeEntry'(m) = ee ims ig Jae 


=u itn = = 
in 
AdeEntry’ 
endlet 
endfun os 7 
RAdeEntry: AdeEntry XN— AdeEntry 
Function RAdeEntr AdeEntry,n) as a ce 
let AdeEntry(m) = AdeVaKm) if m * a 
=! gab ns 
in 
AdeEntry’ 
endlet eae ree 
45.3.1 The Copy Operation es 


Before describing the ‘Copy operation, fev-ay fire révier Oeibintract representation of a 
structure on the VIM heap. “The ‘héip is ria Bled wha’ rected “graph j jn which every node is 
labeled with a unique identifier. Nodes on the heap correspond to structures in our system. This 
representation allows for structures to be components of other structures, ee an ARRAY of 
RECORDS. In our discussion, whenever we refer to a VIM structure, we also include this to mean 


all of the component structures which this structure references unless we exptictily state 
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otherwise. Thus, when a VIM structure is to be copied to:the backup heap, it is also necessary 


that all component structures be transferred as well. 


In order to preserve information found on the VIM state, it.is necessary to have a function 
which can transfer data from the heap and environment:components of the VimSzate to their 
respective counterparts in the BackupState. This Copy function is given below: 


Copy : (U,, U Scalar) x H x BHeap — H X BHeap 
Function Copy (Val,H,BHeap) 


let NewH, NewBH = 
if Val € Scalars 
then H,BHeap 
else let PN nai . 
RefStruct = {u| Im€N, R € Record st 
H(Val) € Rec A H(Val) (m) = u} 
Uy .Up,...,4, = elements of RefStruct 
ECStruct = {u € U,,| H(u) € ECQ A Step Val) = u} 


NewH’, NewBH’ = 
if ECStruct = {} 2 
then if RefScruct # {} 
then Copu,, 
(Copy (thy. 
(Copy (u,), HBHeap)...) 
else H,BHeap 
endif 


else AddBack(H, ECStruct), BHeap 
endif 
in 
NewH’, 
if ECStruct = {} 
then AddBH eapl NewBH’, Wal; H(Val)) 
else Add B Heap( BHeap. val, ({notcopied})) 
endiet es 
in 
NewH. 
NewBH 
endict 
endfun 
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The Copy function takes as input the uid of the structure:to be copied and first determines 
if there are any early completion elements in the structure, If there are, the structure is not 
copied; instead, those fields which are early completion queues are augmented with the special 
flag back. The function, AddBack, takes as arguments the catrent heap and the set of uid’s 
which reference early completion elements i in the suvcture. As retums a new heap in which the 
flag, back, has been added to each of these early completion structures. Determining if there are 
any early: completion elements in the structure requires that all component structures be 
examined to see if they reference any. such. elements, : The function Step takes as input the uid of 
the top level structure and returns the set of all uid’s referenced from any substructure 
referenced from it that is associated with an early completion structure on the heap. 


If there are no early completion elements in the structure, then it is transferred to the 
backup heap. Since a structure may reference many substructures, the Copy function copies all 
substructures referenced from the structure by -recursively calling itself. A structure if fully 
copied only when it atid: all substructures it referenices have been placed on the backup heap. 
While the Copy function is easily expressed in our abstract model, it is significantly more 
complex in the actual implementation. We address. the implementation problems in the next 
chapter. 


4.5.4 The Shell 

The command log contains the text. of the shell. comand input and the name to which the 
result of evaluating this command shouldbe: bound.” This information is used by the recovery 
system which reinterprets the command text. The computation record associated with the log 
entry is used to avoid unneccesarily reexecuting operations whese results have already been 
recorded. Maintaining this information requires modifying the operation of the shell. The shell 
must now, in addition to the stream of shell commands and current Kias$ tate;.also take as input 
the current BackupState. It returns a new VimState Fesulting’ from: the evaluation of these 
commands and a new BackupState which contains a new log entry. for every command input. 


Shell: Session X VimState X BackupState + VimState X BackupState 
Function Shell (Session, VimState. BackupState) 


let <Act, HOEIS, Env> = VimState 
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<Log, BHeap, BEnv> = BackupState 
NewState = - 
if ChooseToExecute (VimState, Session) 
then ShelK'Session, Execute (VimState, ely, sci aaa 
elseif « n)- 
then VimState, BackupState 
else let c, = first(Séssion) 
in ite, Cj = DELETE 
then <Act, H, EIS, DelEinEny, Name)>, BackupState 
elseif c ¢).C= BIND 
then tet % cofimmanitis BIND 


FA=T ranslate(e, 7 
4 = newuid ftom U, 
ye, = AddAct Act, u Fa * FA) 
NewEIS = ‘EFS: tetading 4? DPF AG) ss oc ad 0 
A FAQ)sigent = 0} 


u, = anewuid'in U, | 
NewAde = “ity, fepply}unde> 
BHeap’ = A Sr gee Hetil NewAde) 
Logentry.= we <0. 
eee ice 
State’, v = Interp(State, Choicd NewE1S)) 
<Act’, H’, EIS’, Env> = VimSiate’ 
Env’ = AddtoEny (Envy, C,.name, y) 
in 
<Act’, H’, EFS’. Env>, 
<NewLog, BHeap, BEny’> 
endlet 
endif 
endiet 
endif 
in 
if empty (Session) 
then if E7S"* {} 
‘then Shell (Session, Execute(Newstate, Chote EIS) 
else Newstate, NewBackupState- * 
endif 
else Shel rest Session, Newstate, NewBackupSiate) 
endif 


endiet 
endfun 
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The new log entry constructed by the shell contains the text of the ‘command input and a 
reference to the root of the coniputation tree to be: associated ‘with | this” ‘computation. The uid 
field in the root activation descriptor entry contains the uld of the setivation being instantiated. 
Its AdeEntry is undefiried since no functions have been applied f from this activtation yet, The log 
can be thought: 6f'aS an array of log entries, The shetl' updates 


3 the’ og by adding the new log 
entry to some currently undefined index, Note that the jaterpretesis,only invoked after the log 
entry has been recorded. The shell acknowledges a asa input by demanding the next command 
in the input streart onty when the’ current shell domindnd has Been ‘noted on the backup store. 
This guarantees that no processing will be done on a computation which cannot-be recovered 
from failure since the text of the command is used by thie rebovery, ptovedhures, to reexecute the 
command. The two functions which are responsible fox updating: the, eavizonment, DelEnv and 
AddEnv:raust also be modified, ‘The DelEnv s  seapceatte Rat feehoving an’ environment entry 
from the current envrionment. Since erivironment | bin dj I $3, AFe also, part 4 of the a state, 


- DelEnv must remove the entry from the BEny as well, 


4.5.4.1 Removing Log Entries 
The AddEnv function is responsible | for. adding. a.new, Comal binding to the current 
environment. The: backup systent-nidintairs ‘infomnadon iit the forint ofa computation record 
about the computation that produced this value. This computation record need; be. kept on the 
backup store only so long as the binding was not placed in the image of the enviroment kept on 
‘the backup state. Once the binding is placed in the backup state environment and the result 
._ Value is fully defined,.the. computation ree: assecieied swith: the evaluation Of this contmand can 
_ be removed from the backup. one It may be the case, homeyes, that the fesult value contains 

early completion structures, preventing it from being.eapied ania tha-beekup heap. Thewalue 
_ component in the binding in this case is notcapied,, In.guck, instances itis,the responsibility of 
_ the SET operator to remove. the. ion..pacord. when; the value: becomes fully, defined... If 


there are. no early completion. structures. in. the pesult;yalue. she Addiar function places the 
binding on the backup environment and.removes, the log entry, for. Bs computation as well, 


ey ee 


80 A FORMAL MODEL OF BACKUP AND RECOVERY 845 


4.5.5 The Interpreter . 

Because base language instructions will be now be operating.on the backup state as well as 
the VIM state, it is necessary to alter the behaviour of the interpreter. The interpreter is now a 
state transition function from a VimState, a BackupStase, and.an enabled instruction to a new 
VimState anew BackupState and a result value. Its definition is given below: . 


Interp: VimState < BackupState x EI — + Vim tate x BackupState x Uy U Scalar) 
Function Interp (VimState, Back sine (ud) ui is an, enabled instruction 


ket 
<Act,H,EIS,Env> = VimState 
FA = Act(u) 
<Log,BHeap;BEnv> = BackupState 
NewV imstate, NewBackupState, = [itis SichesBackupisiase tu,d) 
NewVimstate’ = Failure (NewVimstate) 
<Act’.H’.EIS’, Env’>'= NewVimstate’ 


if failed NewVimstate) 
then Recovery BackupState) 
elseif FA().0pcode = TERMINATE 
then NewVimitate’.NewBackupState.FAC).oprumt 
else Intenp(NewVimState.New RackupSaate.Choied EIS) 
endif 
endiet 
endfun | 


The Failure finction models ‘the introduction of a failed state in the system. It returns 
either the state failed or the state passed to it'as input. The function Jailed returns true if the 
new state is a failed state-and false otherwise. Wheti faifed'teturns true, the interpreter invokes 
the recovery procedures to restore the system to a corfect State.’ The model of failure given here 
is, of course, simplistic insofar as it assumes that a faiture’ does not occur during the middle of 

instruction. exécution. In the actual’ implementation ‘of the system. care must be taken to 
guarantee that copy operations on the backup store ure performed ‘atomically. The model given 
here, however, is convenient for expressing the salient aspects of the backup algorithms, 
abstracting low level details such as preserving atomicity of copy operations. These issues are 


addressed in the next chapter. 
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4.5.6 Function Application 
In this ‘section, we present the modified operational sentantics of two of the base language 
instructions responsible for function application in our system, the APPLY and the TAILAPPLY 


ay “Ae vb 


instructions. 


4.5.6.1 The Apply Instruction z 

The effect of executing the APPLY operator is to augment the number of activations in the 
VimState. The addition of a new activation is reflected on the backup heap’ by adding a new 
activation descriptor entry for this new activation and creating a new AdeKpury. function in the 
ADE of the currently executing activation. This new function maps from offset to uid where 
offset is the instruction number of the APPLY operator and uid is ‘the | unique identifier of the 
ADE representing the new activation on the backup heap. The new ADE will contatty in its uid 
fietd, the uid of the new activation; its AdeEniry field is set to empty, and its type field is 
initialized to apply indicating that, this. activation. was instantiaied -by. an APPLY. instruction. 
Since the resylt of this activation is not yet known, iis Results get io urndefined, . 


pi Gs & 


Cup Jree> = H(C), 


ue = anew uid from U 
u’= neal feat 

Act = AddAeteAct, u!:tifa)),: ae Ol kate, ES 
H’ = AddHeag Hu’ “MakeDesd Ht Messy. 


Act’, NewEis’ = 
SendTaDest _ 
(SendToDest 
(SendToDest satis 
(Act. Newkis, u’, <uncond, Lap, Q. tee Ses 
u’, <uncond, 2. op!>, arg) 
u” <uncond, 3, Opt>. wu), 


Uy, = a newuid chosen from u 
‘néwade = <u’. empty. fapplyh undef>, 
BHeap, = AddBHeayt BHeap.t Mya newade),” 
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BHeap, = if3 u, St Bheap (uy) = = Xu, 4, AdeEntry, Type, Result>, 
then let AdeEniry’ = NewAdeBntex BHeagtu,) AdeEntry, u, i), 
Update Ade = = Cup. y AdeEntry’, Tne, Resulb, 


jg eS A ES 
AddB Heap{ BHeap, , u,, Update Ade) 
endlet 
else BHeap 
endif 
in 
<Act”, 
HH, 
NewEis’ , 
Eny, 
<Log,BHeap,BEny> 
endiet 
endif 


It is possible that there is no © computation’ tecord on the’ backup heap that contains the 
activation descriptor for the activation ‘in which the APPLY instruction is found.” This | may 
happen if the result of the computation has already been bound i in the backup environment 
before the APPLY executes. In this case, there is no change to the backup state. If'there is an 
activation descriptor corresponding to the current activation, its AdeEntry is updated to reference 
this new ADE. — 


45.6.2 The TailApply Instruction 

The TAILAPPLY operator is also modified to monitor the progress of tail recursive 
functions. If a TAILAPPLY operation executes as part of. a tail wwecursive activation, we copy ‘the 
argument record passed as the second inptit to the ihstruction to the ‘backup heap, replacing the 
old argument record found in the activation descriptor entry. As we mentioned earlier, doing 
this substantially reduces the time needed to reexecute a tail recursive furiction. Copying the 
argument record becomes a non-trivial issue, however, because: of. the. _presence of early 
completion structures. If.the argument record to be copied contains early completion elements, 
the copy operation can only take place after all such elements haye been set. The old argument 
record on backup heap and the AdeEntry component cannot be pepeaces until the new record is 
fully copied. To ensurc that this restriction is observed. iti is necessary to create a new ADE 
corresponding to this new activation. We now need. to link: the old ADE and the new ADE 


together. Since the idea of noting the argument record on the backup heap is to avoid 
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reexecution of prior tail recursive calls, we interpose the new ADE. between the activation 
descriptor corresponding to the current activation and its parent ADE. The parent ADE 
represents the activation in which the initial call to the tail recursive function was made. In this 
sense, the computation tree built from tail recursive activations is constructed "bottom-up", with 
old tail recursive ADEs being pushed down the tree and new ADEs bethg fitted in between its. 
caller and the original caller of the function. We illustrate this process in Fig. 19, When an 
argument record is copied, we set the AdeEntry field in. the descriptor to empty, effectively 
discarding prior ADE’s associated with this function. Thus, once an afgument record is fully 
copied, all previous ADE’s of this tail recursive function are-removed from the backup state since 
the link connecting these activation descriptors with the rest of the computation tree is severed. 
The formal definition of the modified TAILAPPLY instruction is given below: 


C = Lop, 
arg = [.op2 
dest = [.op3 


<u, free> = H(C) 


u’ = anew uid from U 

Act’ = AddAct(Act,u; Hu) 

Act’, NewEis*s= 

SendToDest 
(SendToDest 
(SendToDest 

(Act’, NewEis, u’<uncond,Lopt>, OQ 
u’<uncond,2,0pt>, arg) 
u’,<uncond,3,opt>, dest) 


Act’, NewEis” = SendS. ignal Act”.NewEis’au;. ottestinations) 
pie & 


Uney = New uid from Up . 
BHeap, = if ree st: BHeaphu, i on uacunriee Result> 
Adel nin k) = = gy BECO 4 )'= "mj, 
jee AddB Heap BHeapu,< a. cate 
New Adebnin( Aden. vAXxType Resuld) 
else BHeap 
endif 
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L 2 
After first tail recursive call Second recursive call 


Computation Tree C 


Computation Tree C 


3 


After argument record of second call copied. 


Figure 19: Recording Tail Recursive Functions 


H’,BHeap, = if BHeap, = BHeap 
then H, BHeap 
else Copy(arg,H.BHeap,) 
endif 


BHeap, = if BHeap,(arg) # aca do 
then AddB Heap Ritleap,u,, wwempty,tailapply. arg) - 


elseif 3. Ung, Sk penta = pg 
abee let AdeEntry’= ew Ade. a) 
in 
Add B Heal BHeap,.u oe ku sAdeEntry’ stailapply. arg>) 
endict 


clse BHeap, 


B+ Thies opt 
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, endif -- 
in 
<Act’™”, 
H, 
NewEis” 


Eny>, 
<Log, BHeap ,,BEnv> 
endiet 
endif 


The backup fiéaie is modified in ies steps by the TAILAPPLY operator. In the first step, 
the ADE of the activation which initially instantiated, this tail’ recursive, function i is modified to 
have its AdeEntry field reference the: activation deattipwor odnsetucted for this new application. 
This new descriptor has its AdeEniry field initialized to reférénce the, ADE of its caller. If no 
such ADE exists, then no change is made. In the next step, the argument record is placed on the 
backup heap. If the copy operation was successful, then, i in the third step, the ‘AdeEntry field of 
the newly created descriptor is set to empty since the reeosery pagcedure can use the argument 
record directly during the restoration of the system state. If the séfiéture was not copied, then a 
reference in the AdeEntry component of the new agtivation ig set to ifs caller Ade. This allows us 
to still reference previous activations of the at tatdeave farieton ‘until the argument record is 
finally copied. 


4.5.7 The Return Operator - | : 

One of the important features of our backyp-algorithm is that results of activations are 
recorded on the computation tres. This. is the prirheaty ‘means of reducing reexecution time of 
volatile shell commands. The RETURN. operatar. transmits the result of an activation to the 
backup heap. The return value, .if it is a VIM strtseture will, in most cases, contain early 
completion elements. The SET operator is responsible, in these, ‘iumstances, for ensuring that 
the structure does finally get copied. If the return value i is copied, thett:all ADE’s referenced 
from this descriptor are removed from the backup state. This has the effect of pruning the 
computation tree. Because ADEs can be removed in this manner, it may be the case that when 
the RETURN instruction executes, there maybe no ADE associated with its activation since a 
return instruction in a parent activation may have placed its result on-the backup heap. In this 
case, no action on the backup state is required oY the instruction. The modifi ied cepenton of the 


instruction is given below: 
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if opcode = RETURN then 
let 
DL = H(Lopt) % the list of return addresses 
u, = DL(1) % uid of the calling activation 


targets = GetDest( H,DL(2)) 
Val = Lop2, % the value to be returned 


Act’, NewEis’ = SendValue( Act,NewEis,« ; targets, val) 
Act”, NewEis”, = SendSignak Act’, NewEis’ te a 


Ade = Xu, 4 AdeEntry Type Resul 
BHeap, = if u, st. BHeaplu, = Ade 


thea AddBHeapl sae a iF Adena wer) 


else BHeap 
endif 


H’,BHeap, = if Val € Uy . 
then Copy Val,H’ -BHeap’) 
else sia ae ee 
endif 


1: ie BHeap, = = if3 uy st. BHeap. {up = ond 
thea: if BH: (vai) oz) 
then nbHep, 
else let 
ia {n| AdeEntr{n) is eee 
woot, = k elements of Ref. 
Gethin = RAdeEntry... 
maprein deniers eri n De n ~)” 


NewAde = up vAdeEntry ,walste, Vad 


in 
H’,AdaB Hep BHeap,,u,,New Ade) 
endif 
else H, BHeap 
endif 

in 

<Act”, 

H”, 

NewLis” 

Env, 

<Log. BHeap,, BEnv> 

endlet; 


endif 


RAE ORRIN Pe Bitban ts See TS 
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The backup heap is updated in three steps by the RETURN instruction. The first step 
determines if an activation descriptor for the current activation exists £2 ifthis activation has an 
ADE which is part. of some computation tree.. If so; the type of this activation “descriptor is 
changed to: value indicating that-a result has been created andthe’ return value is writteit iitto the 
_ result field of that ADE. ..If the return value:is:a'structare; thet we inktiate a Copy operation to 
place this structure on the backup heap. If the structure’#é fallycopied because it’contains no 
early completion elements or if the result was a scalar value; ‘thert dll/ADE's referenced from this 
descriptor are removed from the backup heap, .effectivelypruning-the computation. tree as 
discussed earlier. If, on the other hand, the result was a structure contains early completion 
structures, it is the responsibility of the SET instruction ‘to perform the pruning of the 
computation tree. 


4.5.8 Stream Operations 
There are two operations which manipulate stream activation déscriptors on backup heap: 
the SETSUSP instruction and the STREAMTAIL. instruction. These operators are responsible for 
elements and notis ag argument records of activations to 
allow the recovery procedures to reconstruct +e arears image arid to permit demand driven 
evaluation of those elements not recorded. ai 


4.5.8.1 The Suspension Operator 

As we had described earlier, the SETSUSP operator needs to be altered to record the 
production of stream: elements on the backup heap. Coneral: 8° our - algorithm i is the use of a 
stream coordinator record which contains the element produced by a stream producer activation 
and the argument record to the STREAMTAIL instruction used. to initiate, the nextactivation of the 
producer. When a new.stream activation is instantiated,-a-new-ADE-is created for it. Unlike the 
case with the APPLY operator, however, ADE's, created. by the STREAMTALL instruction. are 
accessed through the stream coordinator record. The-link field-in-the-coordinator-record is used 
to link together all stream activation descriptors in a chain.’ mitrsting ‘the construction of the 
stream on the VimState. The SETSUSP instruction is responsible for iniially- creating the 
coordinator record and for linking the clements in the backup stream‘ “ittage. -When the 
STREAMTAIL instruction exccuics, it initiates the copy operation for the argument 1 cord of the 
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new activation being instantiated. In addition, it sets the link field in the coordinator record of 
its corresponding ADE to that of the new stream producer activation. 


The SETSUSP operator takes as input the record nepresenting the new stream element. It 
updates the ADE associated with. this activation to type stream. and constructs a new stream 
_ coordinator which is referenced from the Result.of this. desctiptor. It then initiates the- copy 
operation for this stream element. Each new invocation of the stream: producer causes a new 
ADE to be constructed, with the link field.in the coordinator of the:previous activation set to this 
new ADE. In Fig. 20, we illustrate the effect of the SETStSP instruction on. the backup heap. 


After a SETSUSP operator in activation with uid u executes 
and stream element recorded. eas 


Figure 20: The Effect of the sersusp instruction on the Backup Heap 


The format definition of the SETSUSP operator is given below: 


if /Opcode = SETSUSP then 


let 
u= fopi 
R= Hu) 
S= 1op2 


i= lop3 
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Act’, NewEis’ = SendSignal Act, end 


RO) = ROMVAS ts te ee oh 
= MakeSusp(<u, oth 
strecord = (RE), tonhef sites tit resin a nol known yet. 
ie BN eap, FA HR(O:E pec P oopvoctis arte tei. sobs 
then Co 
“se H”’ 
eit es " a 


“= anew uid from U parae ts si : 
Bieap, dh arc pee 
aera o ty! ty ae F t 
H” BHeap, = = Way, st BHea (u = sce Te 
the AY" Maat 
era Coe WILE roa SBE PEL ees 


in 


HERG) € ECQ A IRD = Aa | or 
:. the €4o0f, mye rou Po FW moi HG ae oo 


ese! ‘et cer bi “e Sono vou uta iat sil) 


fim “i STATM AUST? ant of boegaq byo0 


hp ta Sg be aE a : Me tel 
Eny> : ag eet go peas : be age ulate atte Cos 
meriibeth Sate Maw UAE Ge a are ea Wee Sr 


. Pees kM GB) day (93 89.) P83 e$ 
. - + : a om raphe 
é 7 1.8 f setts ie fo ie face tye git, pers Meret ty A base Bite “tig 
endif zeit fee Pxag Chock tae Law QUEUE TEBOW nT Oe 
: n 
: é 4 
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There are three major tasks that the SEFSUSP operator is responsible f for i in ihe update of 
the backup heap. The first is the construction of the stream coordinapep record: It creates a 
record, whose first component is the Vi@Ge: of the new Urtatetl tein ERévient, ‘and the second 
and third components are given value, undef. This second componenpis to hold the, value of the 
argument record but may only be defined when the STREAMTAIL instruction in ‘this activation 
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executes. The third component holds the link to the ADE of the next activation of the stream 
producer and can also only be set when the STREAMTAIL operator executes. The second task is 
the copying of the value component of the stream record. Recall that our definition of a non- 
empty stream element is a record of two fi elds, the first being the element itself and the second 
holding the suspension to the rest of the stream. The. backup: facility need only copy the first 
element of the record since the link field to the next ‘stream element can be set by the recovery 
procedure when the stream is reconstructed. The third major task: that the operator performs is 
the updating of the activation descriptor entry associated with the stream producer. It changes 
the type field of the ADE to stream. and updates the Result to, reference the new stream 
coordinator record. We next examine how the STREAMTAIL instruction needs to be modified to 
maintain a consistent and up-to- -date i image of. stream production. | . 


4.5.8.2 The StreamTail Operator 

The STREAMTAIL instruction operates in conjunction with the SETSUSP operator in 
maintaining the stream coordinator records and activation descriptors. When this instruction 
executes, it initiates the transfer of the argument record passed ‘as: its second argument onto the 
backup heap. The stream coordinator corresponding to this activation is. updated to reference 
this argument record. If both the value field and the argument-fécord:are fully copied, then all 
subordinate ADE’s can be removed from the backup heap. In this sense, the stream value and 
argument record passed to the STREAMTAIL instruction constitute the result value of this 
activation and just as the computation tree is pruned by the RETURN instruction when the return 
value is placed on the backup heap, we perform the same action here when both the stream value 
and argument record are safely recorded. Like the TAILAPPLY instruction, STREAMTAIL is also 
responsible for creating a new activation descriptor. The type ‘of this ADE is set to stream and 
the link field in the current stream activation record is set to the uid of this descriptor. We give 
the formal definition of the STREAMTAIL instruction below: 


if opcode = STREAMTAIL then 


let 
C =/opt, 
arg = /.0p2 


dest = 1op3 % dest is a field in a stream record 


<up free> = H(C) 
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There are four steps that the STREAMTAIL instruction n follows in updating the backup heap. 
The first step is the construction of the activation descriptor for the new, stream: activation to be 
instantiated. In the next step, the instruction calls the Copy fumetion: to: transfer the argument 
record to the backup heap. In the third’ Sep; the trea “ordinator associated with this 
activation is updated to have its argument record refosence thisistructure. Finally, the instruction 
checks to see if both the stream element and the arg iment record have been. copied, and if so, 
removes the subordinate ADE’s frdm the beckup heap. “Wei have avoided describing the removal 


of argument records of old stream coordinatior records w bingiity: ‘the presentation. 
oy Say Te EES a 


4.5.9 The Set Operator 


The operation of the SET instruction is also r ‘ : fi id or information. on the backup 
heap. A structure containing an early . etian ‘element raaicbepariofen argument record to 
a TAILAPPLY instruction or may'be pertofa restit reoded oF activation. In section 4.3, we 
argued that such a structure should augment the ee Staje.only when it and all of its 
substructures are fully defined ie when ney eaters eo early re fataga structures. If the early 
completion queue in the ex-stractre bein, pet Conital cada 1 e he 4 Value back, it means that this 
field is part of some structure which: needs to he xopieth ant the backup heap. In fact, because 
elements on the heap. can'be shared, the strochih chnthininly this field may be a component of 
many structures, some of whom, peed. to. be, sopied -to.,Backup heap. The SET instruction 
examines each of these stfactures: to’ see if = ate any arly completion structures in them 


which still need to get set. ‘Those structures. XD esfully d defined are Et 


. The SET. instruction, also examines those. Pree leo ne or stream coordinators that 
have a reference to any of those structures that become Ritly'defined because of its execution. If, 
for example, there is a value or tailapply Ade ices resulta fipid,seferences a structure that 
becomes fully defined because of the SET instruction, then, as was iste by the RETURN and 
TAILAPPLY instructions, all references to activation descriptors from the AdeEnity. component of 
the associated ADE can be removed. Similarly, if the reference to a fully defined structure 
emanates from a stream coordinator, then the SET operator must check to see T the AdeEntry list 
of the associated stream activation descriptor can be reset using she. critepia\we. discussed above. 
The instruction is also responsible for removing a log entry if the element being set is part of a 
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structure: to- be bound in an environment. one sive the formal definition of the instruction: - 


below: 


if opcode = SET then 
let 
u= [opt 
R= Hu) 
S= Iop2 
x = Lops 
u’= H(R()) 


VvEN 
Ry) = Rv) ifvef 
= x otherwise . 


Act’, NewEis’ = SendSignaK Act,NewEis,u , des dexiinaith ona a 
H’ = NewHeaQlH, u, R) 


Parent = bed u’ € Step{u)} 
| Mylar 4, = Roonponens of Parent eee 


| H’BHoap, = WAGE Qo me as 
saree “Ao ¥. ieee e Bee oes as 
Kohn) SF Fee 
else HBHegp Oe ote ae 
’ “endif ~ ; 


BHeap = it uyse, BHeap,(u =< Ad ipistenea 

> then let Ref = ot | deen n)i is ein > 

a i % ye . st, 2 he 
Sto enna 

in 7 Type = value V Type = a 
, thea ten * NORCOPIEA,;: 

Lette san ie) 
ebe Pe sca. 


elscif Type = stream 2 
then let <val.arg. link> = Bent) 
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AddB HeaphBHt exp, uu F pen eee Ue. ?) 


ele H™, 
BHea, 
——endlet 
— else H,BHeap 
endif 
endlet 
else BHeap 
endif 
NewLog = CheckLog( Log,Parent) 
in 
<Act’, 
H, 
NewEis’ U H(u) 
Enyw, 
<NewLog, BHeap,, BEny> 
endlet 
endif 


WEEE. O 


Because objects on the heap can be shared, the record ‘whose field’ is being set may be a 
substructure of several objects. The set Parent denotes the did SUF these 'sttu ctores: Recall that 
the auxiliary function Step when given the uid of an arly sce pledon structure returns the set of 
all uids associated with structures which dave spath omile ‘heap to this ec-structure. If the flag, 
back, is found in the early completion queue, the indtrichion ‘calf the Copy function to attempt 
to copy all those structures whose uid’s are in shan This function will only copy those 
structures which do not contain’ any other early C mm one ai anit » The backtip Heap retumed 
from the calls to Copy will contain all those structures referenced from Parent which were able to 
be copied. because they noilonger contained any Ar-structafen, 


If the activation ddescipene referencing 4: copled strlictute was of type value or tallapply, 
then the subtree rooted at the ADE is removed. ‘If, on the other hand, this structure was 
referenced from .a -stream cogrdinator ‘recdftt, ‘the “iristruction removes the subtree of the 
corresponding stream activation descriptor if both. the value and argument field in the 
coordinator have been sil ates defined shot 


We also introduce: one: ‘other auxiliary function; CheckLog. Some of the structures in the 
Parent set maybe values which are to be bound, in the user environment. Among these 
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structures, there maybe some which are now’ fully defined'as a result of executing the SET 
operation and are placed on the the environment image:on the-dackup state. These structures 
_-are the result values of active: computations. These computations are represented-on the-backup 
“heap. as computation records which are: referenced ‘from ‘the -enwies'in the command’ ~ The 
function CheckLog removes these log entries and returns the new log. : 


4.6 Summary 


In this chapter, we presented the backup and n recovery algorithms for the viM system. Our 
attention focused on the representation and manipulation. of f computation records, whieh goatain 
information about the progress of volatile commands in the system. A computation record is 
represented as a directed tree where nodes in the tree denote activations and edges signify 
caller/callee relationships. To update a computation record requires altering the semantics of 
the APPLY and RETURN instructions. The APPLY operator adds a new node to the tree and the 


RETURN operator replaces a node with the result value of its corresponding activation. | 


A node in the computation tree is referred to as an activation descriptor entry and embodies 
information about an activation in some active computation. There are two basic types of 
ADE’s: apply and value, the former used to denote an activation whose result value is not yet 
known and the latter designating an activation whose value has been recorded on the backup — 
heap. 


The main disadvantage with this simple scheme is that it is not sufficiently expressive to 
handle early completion or stream structures and is inefficient when tail recursive functions are 
involved. Early completion is handled by requiring that all ec-elements in a structure be SET 
before the structure is copied. Ensuring that such a structure eventually does get copied 
necessitated the modification of the SET instruction to update the backup heap when the 
structure becomes fully defined. Tail recursive functions are represented on the backup heap 
using a special tailapply ADE which holds the argument record of the tail recursive activation. 
We based the design of the tailapply ADE on the observation that the recovery procedures 
could avoid executing intermediate activations of a tail recursive function if the argument 
records to the activations of the functions were recorded. During recovery, the function could be 
instantiated directly with the argument recorded found on the backup heap. Finally, we 
- introduced a spccial descriptor to handle stream structures. A stream ADE contains a reference 
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to a stream coordinator record which embodies inféermation: about ‘a stream activation. In 
addition to storing the stgeam element: produced in: thad:aetivation; we:aiso keep the argument 


Fecord needed t produce the next stream-element..: The gonstruction:and maintenance of stream 


coordinator records. required :modifying. the: operation of :the.“SETSUSP: and STREAMTAIL 
instructions. 


The algorithms presented in this chapter were developed for a very abstract 1 machine in 


which such issues as structure organization, guaranteeing atomicity of information transfer from 
I PEQES 


memory to backup heap, ‘andt memory managément of th the backup heap were n not addressed. In 


. the next chapter, we discuss these issues babs 
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~_ Implementation Issues | 


In this chapter, we are éoncemied with concrete problems that a arise when we attempt to 
implement the backup algorithms presented in Chapter Four for the VIM system. These 
algorithms were described i in the context of an abstract model MR which was used as a vehicle to 
rigorously describe their behaviour. Issues which were conveniently hidden i in our model will 
- now have to be more thoroughly addressed. In particular, we will focus our attention on how the 
Copy function may be implemented. The complexity of. the operation arises because of the 
representation of structures in our system. Guaranteeing that the copy operation will always be 
atomic is a non-trivial: task given the storage representation: for: data: structures that VEME-uses. 
Section 5.3 concentrates on this issue. Section 54 neiuanain ey storage management policy 
for stable storage, 


5.1 The Copy Operation ; 

The. copy. operation, as described in Chapter Four, is responsible for copying a VIM 
structure object to the backup heap. An-efficient implementation of this operation is‘ necessary 
_ for any practical realization of our backup algorithms. In our abstract modet: the copy operation 

- was treated as a function which transmitted the success of the copy Hack to its caller. The calters 
_-Of this function were base: language instructions that required: resuit values or argument records 
to be placed on the backup heap. There is-no-concurrendy-bétweert the execution of the caller 

_ée. instructions and the Cepy function ‘in this model. Aw instruction that'calls the Copy function 
_ Must wait for the copy to be complete before it can® continue execution. In an actual 

implementation, having the interpreter wait for the trarisfer of data from memory to stable 
storage before beginning execution of the next instruction. woukd' lead to ‘intolerably slow 
‘performance. Examination of the formal description of these instructions, however, reveals no 
reason why the transfer of data to stable storage cannot proceed in paralfel With the’execution of 
other. instructions. Our approach to implementing the backup algorithms is to’ consolidate the. 

“logic” for modifying the backup state into a backup.-system kemel that is responsible for 

updating the computation records on backup store and initiating the copy operation to perform 
~ data transfer to stable storage. Base language instructions invoke: the kernel. passing as 
arguments, the type of operation to be performed ie set. result, tailapply etc. and the necessary 
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operands ie data structure to be copied. The instructions can then proceed with normal © 


execution without having to wait for any results from the kernel. The responsibility of updating’; ~ 


the backup state would then be primarily in the purview of the backup system kernel. 
Overlapping execution of base language instructions with transfer of data to and from backup 
store makes the backup algorithms presented a much more attractive solution. If sufficient 
concurrency can be exploited i in the base language programs, then we conjecture that updating 
stable storage should not cause major degradation i in system performance. 


An important requirement of the Copy function is that it be atomic. In database literature, 
atomicity is a property of a transaction whose overall effect is all-or-nothing: either all the 
changes made to the data by the transaction happen; or none of the changes happen. Thus, all 
transactions appear externally as. indivisible operations.: This requirément is essential to support 
recoverability of data after hardware failures occur. Atomicity in- VIM is a property of an 
activation that refers to the point at which the effects of the activation are perceived. by other 
executing activities in the system. It is necessary that the Copy function be atomic because the 
effect of its execution ie the augmenting of backup state information, should be made visible to 
the recovery procedures only after the entire structure hes been completely copied to backup 
store. If a failure were to take place during the middie ofa. copy operation, and.the function was 
_, not atomic, the recovery system would see: data in’ the backup state that. does not correspond with 

. any data that was present in the .Vim state at the time. the fhilure took place. Guaranteeing 
atomicity is a non-trivial issue for two reasons. First, data structures.in Vim may be arbitrarily 
complex; if the structure to be copied represented anode a on the VIM heap, then the entire 
. gtaph rooted at a must.also be copied onto the backup heap. ‘The other complexity involved 
. with the copy operation is due to-the way data structures are represented in: VIM. We discuss the 
_ Storage organization of the Vim heap in the next section and -then present our solution to 
_ guaranteeing atomicity for this operation. 


_ 5.2 Storage Organization in Vim 

VIM structures have been thus far treated as monolithic entities that are created and 
manipulated as a single unit. This representation was useful in the presentation of our backup 
and recovery algorithms. but is far removed from the actual. representation of structures in our 
system. The representation chosen for structures. in Vim is influenced by the organization of 
physical memory and the desire to have only information needed ‘by the computation be resident 
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in main memory. VIM is based on a hierachically organized physical: memory consisting of main 
memory and disk in which information is brought,4gte.main,memory only upon demand. To 
facilitate the transfer of information between memory and disk, the virtual address space is 
partitioned into a number of fixed size pages. The organization of the address space in VIM 
differs from conventional demand paged systems, however, in the page size chosen. To avoid 
the overhead of unnecessarily paging in unwantéd information, the unit of storage allocation in 
VIM is a small page of 24-32 words, known as a chunk.- Having a small page size is the primary 
means of exploiting parallelism in base language programs. In our data flow execution model, 
there is no dependency between any two enabled instructions. and thus, I/O service required by 
one instruction does not prohibit the: execution of the other in the interim period. By having a 
high level of concurrency of data transfer between the disk and main memory, the processing 
unit is seldom expected to be idle waiting for a pending I/O request to be serviced during 
program execution. It is expected that, in general, there will be enough enabled instructions 
during program execution to make disk access completely transparent. 


Because of the small page size eed each chunk holds at most a single object. Complex 
structures such as arrays and records are held in a number of chunks. The representation chosen 
’ for these structures should be sensitive to the applicative nature of the programming model by 
allowing information to be shared between structures whenever possible. One implementation 
well suited to our goal of efficient sharing i is to represent. viM. structures. as k-ary trees of chunks 
with the leaves of the tree containing the elements of the structure and the internal nodes of the 
tree containing pointers to other chunks {17}. Because structures-can ‘be complex, leaf chunks 
may hold uid’s to other structures in addition to containing scalar values. .The choice of a tree 
organization to represent chunks-allows.a high degree of sharing-to be achieved: For example, to 

construct a new version of a structure differing: from i its et | in a a single pene the 
is to hold the new element; all other elements which are stiff ‘common'to both : structure’. are still 
shared between them by having both structures use the same paths to the’ common deaf chunks. 
The REPLACE instruction briefly described in Chapter Two, for example, which retums a new 
version of a record differing from the old version in a single element operatesin this: »manner. 


The address of an element in a structure is cause ed aah a wot. éuid. A. acesipath. uid 
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offset of the desired element in the structure. The ne of the access path for a given structure 


is the height of its VIM tree representation. 


Internal chunk cl 


Internal chunk c2 


leaf chunk | 


k elements in this chunk 
Figure 21: The Representation of'a Vou stricture ack 


. Abstractly, we view a chunk as a three tuple: 


Chunk = : Cid x Header x Data. 
Header = NN 

Data = Internal U Leaf 
Internal = Cid” 

Leaf = = (U U Scalar)” 


Cid = the an of chunk identifiers. 
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The Cid of a chunk is the chunk’s unique identifier and maybe thought of as the virtual address 
of the chunk in the system. It:should be noted that the:demait-of chan id’s is not-related:to the 
_. domain of structure uid’s which are used to uniquely identify objects’ on: the Vim heap. ‘The 

__ Header field-in a chunk contains administrative information about the chunk: In particular; the 
. Rumber of references-to.this chunk in the syste the height Of thie sleunk ir the Vim tree, and 
__ the high and-low indicies of the elements of the subtree rooted al this crunk aré ull information 
_.. kept in the header field. If-a chunk has no- outstanding references to it, 1 is paced on a Sreelist 

_. and its space may be reused when-needed::: The taét compan ent ig the ‘dita ’portion of the chunk. 
For an internal chunk, this consists. ofthe €i7's: of itp -bravediate ‘Gescendents im the'tree. For a 
leaf chunk, this consists of either uid’s if the. elements of this a rh aera teh themselves. structures 

or scalar values. The size of the data portion is some fixed. m. The size of the chunk i ism plus.the 
size of the header | portion. 


For a seasicee description of the:storage organization-of Vim-structure, the reader should 
see [17]. In the next section, we. examine the problem of making the-copy: operation atomic. 
‘Structures which are to-be-copied from: the Vincdneap ofits thé ‘backup heap must be copied 
atomically ie, a structure consisting of many chanks atinuld ‘be deemed es being copied only 
when all of the chunks which comprise it-have ‘been wransferedvonto ‘baskup' store: and ‘not 
before. In our-discussion,.we shall refer to a:chunk fowndiin main’ stove as a Vim’ chunk tind a 
p chunk found on. backup store as:a backup chuak:' We'sialt use thie Wond: structure to refer to any 

“VIM structate. ag. array or record. . save ye ; 


33 Performing the Copy Operation 
_ When a dase language: instruction which needs to-dugment tiie ‘backup state executes, it 
_ invokes the backup :system kere!’ which maintsins af Ioférination tibout' thé current Status’ of 
structures which-are in the:process of being chpied: Fheudemelds responsible for updating the 
_computation tree and command dog: on bavkup:-store babed2Gn dle aigoritems giver in Chapter 
, Four. -When a structure is 40‘be-copied; the kerrie! calls the Copy fuliction:: This function takes 
as input the uid of the structure to be copied and produces as its output an acknowledgement, 
Copied if the structure was fully copied onto backup ‘store or ¥ nescopied if if i it could not be. The 
latter acknowledgement occurs when a structure or Any ¢ of its Substs ctures) ‘containg early 
conipiction elements. The backup system kernel uses this arknowledgement to determing when 


activation descriptors should be given a new type cand when command log entries can be 


removed. 
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A major complexity in implementing the copy, fenction for the VIM system is due to the 
_ representation of VIM structures. as: trees of chuaks. For. the sake of uniformity and simplicity, 
structures found on the backup heap will also have: the same representation as their counterparts 
on the VIM heap ie. trees of chunks. At the start of system operation, ‘all chunks of the backup 
store will be.on a freelist. Whenever a VIM chunk needs to be copied onto: backup store, a 
backup. chunk is. removed from the backup freelist andthe contents of the Vim chunk are copied 
onto it. This approach will remove-the need for sophisticated interpretation of the data found on 
the backup store by the recovery system. Activation descriptor ee a computation 
record are treated as records which occupy a single chunk. 


To see how the Copy function can be implemented, let us first consider a simple scenario. 
Suppose that the function is to transfer a structure whose leaves contain n scalar values onto the 
backup heap, where n > m. This structure will be represented on the heap as a tree of chunks. 
Let the leaf chunks of the structure be: labeled. //, /2,...,ij: ‘Clearly, these leaf chunks can be 
copied onto the backup heap. without any. preprocessing. by:the:copy routine since the leaves 
contain only data. Let /,62,...b/ be chuaks:on the feestist on:the backup store, Then, the data 
found on // can be copied onto 5/, that of 12 can be copied :to S2 ete. After the leaf chunks have 
been thus copied, the routine proceeds with copying the internal chunks as well. Copying an 
_ intemal chunk is a little more complex because. these chunks contain: references to other VIM 
chunk id’s, The copy routine translates these: references to: their appropriate backup store 
equivalents. Since the copy operation is being performed ina ‘bottom-up fashion though, all 
chunks referenced by an internal chunk would already have been given chunk id’s on the backup 
store. If an internal chunk C has references to chunks cl,¢2/.:,cm, then thé cdtresponding 
. backup chunk has references to 6/,62,...,bm-where. bi is the. backup:chunk id corresponding to /i. 
_ The copy routine updates. the activation descriptor: to ‘reference this structure only when all 
. chunks have been written to backup store. If.a failure takes place before the ADE can be 
updated, it will appear to the recovery system that 1no.information. about this activation was 
recorded by the backup system. Note that all chunks at.a given height in the tree can be copied 

in parallel. 
The copy routine performs a bottom-up breadth-first traversal of the structure. When a 


chunk i is copied onto backup store, its backup chunk id i is recorded in the header portion of the 


chunk. If the copy routine is invoked later on. to copy a chunk which has already been copied 
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on the -backup store, it-can:avoid recopying the'chunk ‘by: first checking to see if that chunk 
_ already has a backup chunk id: By sithply recording these id's; the same level of: ih found 
on the VIM heap is achieved on the backup heap as well 


In this simple scenario, guaranteeing atomicity is a a fairly easy task because the structure is 
not recorded as being copied until the copy funtion transfers all Vim chunks to ‘the backup heap. 
. . The situation becomes slightly. more. complex: when: we:consider:the actions which need to be 

. undertaken, for copying more complicated: structures. In particulary the solution givért above is 
not satisfactory for handling structures: whose slementsiare thenmelves structtires e.g. ah ARRAY 
' Of RECORDS. Let us first.consider the situation without:early pempletion.. Suppose that'a leaf 
- chunk, Ji, which is. to..be copied contains: refereneces:toi other structures on “the heap: - It is 
,» necessary that each of these subordinate structures: mustdthemseives be fully copied bEefsre this 
;. leaf chunk, is allowed 40’ be written. onto. backup store, Quirdescription-of the copy routine in 
-. Chapter Four had i recursively. call dieelf: to copy: tame! gubemracmares ‘When all strdettires 
es referenced from, this chunk have -heen copied; then the leaf-chunte:can’ itself be transferred-onto 

-backup store. Because.the routine only. returns to! ites caller wegers all substructures have. been 

. eopied, the copy action: is atomic since the backup staté wilt Be! apdated to acknowledge the 

__ existence of this structure.only when the top-lerel.copy zoutine-vonapletes aind-retums itt result to 
_ the kernel Because: we are mot considering early: compietion’elements, the Copy filnction’ is 

- guaranteed to retum. an. acknowledgment; cepted,’ No partially copied structure can ever: be 
. referenced by any activation descriptor inet such: references paeecices the’ eerneh after the 
copy operation is complete. 


53. 1 Early Completion 4 . 

The presence of early eaeleisn elements in the leaf chunks of structures’ further 
complicates the copy procedure. In Chapter Four, we noted that it is necessary for the backup 
“system to be able’ to determine when there are flo further carly completion elements stil to be 

SET before the backup: state can ‘be updated. In our iniplementation, we can determine this 
“information through the use of reference counts. ~ Every chunk has two reference counts 
associated with it: the refent i is the total number of references | to this chunk found i in the system, 
and the setcntt is the number of SET instructions still pending which are to set carly completion 
elements found in this chunk. The meaning of the refent is the same for an_internal chunk as it 
is for a leaf chunk. The setcne ficld in the header of 0. injernal.chuak is the number of early 
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_ completion elements which need to be set in the tree rooted:at this. chunk: Thus, the refent field 
in the root chunk of a structure holds the total number of references to this’ structure and the 
setcnt field indicates the total number of early completion elements found within the structure®. 
When an early completion structure gets SET, the setent field i in the headers of all chunks on the 
path to this element get decremented. : 


Let us first consider a simple structure ie one:which does not reference any other structure 
on the heap. To implement the copy operation itt the presence of ‘eatly completion structures, 
we do the following. When-a:leaf:chunk  with:refont:greater’than ‘zero is encountered by the 
_copy procedure, we do not-copy it onto the backup'sore,. Insteatt; welallocate a backup chunk id 
for this chunk .and-continue examining the other:chunks it-this structure, To inform the SET 
Operator which will eventually replace the early.completion ehentent found in this chunk that it 
. Should copy the: chunk onto backup store, the copy routine also dabets te chunk with the tag 
back. At the time the early completion element becomes-defined., die SET opérator will ridte the 
fact that this chunk. belongs toa structure that is to be copied to backup store. If the setent of 
_. this leaf chunk is zero, the: operator invokes the: backup system ketiel't0-copy this chunk onto 
the backup chunk allocated for it. In addition, if there are:no outstanding: SET instructions that 
are to be executed for this structure, determined by examining the setent of the root chunk for 
this structure, the kemel also updates. the: activation: descriptor: tw reference this ‘structure 
according to the algorithms given.in the last chapter. - Notice that orrputation records are only 
updated. when all elements. in a structure are fully: defiried anid copied-onto the backup heap. 
Thus, it will never be the case that activation descriptors are aware of structure for which riot-all 
elements are known. Atomicity is still guaranteed even with early completion structures because 
a structure becomes a part of a computation record only when no fartier ‘ec-elements' are 
referenced. from it. i Lee AE Beate ee 


We next examine how the backup system should: handle early completion : structures 
belonging to structures that are components ofa larger structure which i is to be copied. When a 
leaf chunk which contains uid’s to other structures is encountered by the copy function, the 
setcnt of the root chunk of this subordinate strycture: must be examined, If it is greater than 
zero, it means there are early completion elements which stil need to. be set. in this structure, . _AS 


Orhis does not include the refcnt or SETCH of its substructures, 
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before, the copy routine is recursively invoked to copy. the chunks found in this substructure. It 
is necessary that the backup state does. not get updated with the pasent.structure unless all 
. Subordinate structures of this parent beeome fully defined: :Gur implementation follows-closely 
with the algorithms given in the last chapter. Every. rootchunk:of a structure contains a-field in 
its header, Parent, containing the uid-of all structures’ which sefereace this structure that‘are to 
be copied. This field is:mangaged-by the-copy function as it-traverses the ‘heap. Associated with 
each uid in the list, we also stose the chunk id of the teaf chunk inthe parent structure from 
which the reference emanates. When all early cogapletion:elements are set ina structure that is 
to be copied onto backup store, all structures referenced in:its Parent list are examined: The 
backup state is updated with those structures referenced inthis list. which have become ‘fully 
copied. Determining whether a structure has been fully copied involves keeping track of the 
number of chunks that still need to be transferred and the status of i its substructures, Counters 
are used to record this information. Every root chunk, in ‘addition to ‘the Parent list, also 
*” contains a ToBeCopied counter indicating the number of chunks still to be copied onto backup 
" store. When this value becomes zero, the backup state ‘can be updated, Every leaf chunk also 
contains a counter indicating the number of substructures which have not yet been fully copied. 
When this counter reaches zero, the leaf chunk can .be copied: onto. backup store and the 
ToBeCopied counter can.be decremented. Much-of the'detaillinvolved:in implementing the 
incrementing and. decrementing.of these counters: is. not: very: interesting and is omitted here. 
_ The important point to note with. respect to:early completion is that the backup system: kernel is 
_ responsible, not only for updating the backup. state: with he ‘structure containing the -early 
completion element being set, but also: for. updating. the. backup:.state with all: of its ‘parent 
structures that need to be.copied as well, 


5.4 Storage Management _ . 
_ One other. implementation detail that deserves -brief. mention-is the manner in which 
_ storage management is handled on.stable store. ‘The organization we have choser for stable store 
lends itself to.a very simple and efficient storage management: strategy. Recall that stable storage 
is uscd to hold. transitional data represented in the: form ‘of -computation’ ‘records: Each 
computation record embodies the progress of some active comepulation in tHe system. When the 
result of a computation is recorded on. stable store. the associated computation recorded can: be 
deleted. Deleted computation records are added onto a freelist of backup chunks. We expect 
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that the set of quiescient data found on stable store’ will-be periodically written onto tape. After 
the transfer, the space occupied by these data items:on stable stove’can be reclaimed. It is not 
necessary, however, to wait for the transfer: of informatioty to tape before space can be reused on 
stable store.. Once the result of a:computation is bound ia-an enviroment, the storage occupied 
by the activation descriptor entties of the corresporiditig computation record’ car be reused. We 
use a variant of a mark and:sweep garbage collection ‘polity: ta teckaim structures referenced from 

activation descriptor entries ina computation record-that Gin Be reclaimed. Ofice the result of a 
computation. is:known: and‘is copied. onto the batkup’ store,:allehunks in that structure are 
‘marked. - We can: then: reciaim.all chunks ae to’ stiactares refelenced from: ADE’s in that 
computation that are not- marked, . 


The storage management policy i is very simple for ¢ our system because we can determine 
precisely when data is no Jonger accessible by observing | the dynamics of, the command log — 
removal of an item in the log implies that the associated computation. Tegord can be reclaimed. 
Waiting for a computation to complete before reclaiming t the storage. it occupies on stable storage 
obviates the need for introducing a complicated garbage collection p a policy on stable store. . 


It may be the case that the value of a computation is redorded-on the backup environment 
even before: all the: values of the ADB's in the subteves Of the'computation are. Since the result 
_of the computation has been recorded in the-environmrent the associated computation record can 
_ be-placed on the.backup store freedist. _ Removing thé -corsputiition ‘récord, however, necessitates 
_ taking some. action to inform the activations whee: resists would normally bé teoorded in these 
ADE’s that the computation record: is:no' longer: part of thé-batup heap: To dothis, we 
maintain a uid entry table which contains referencing information for ‘all activations in the 
system. Entries in this table include the uid of the activation, the address of the activation in 
memory and the address of its ADE on backup store and a refertnte to a ‘boolean flag which 
indicates whether the conapattation record: has. been reclalmed:or net. When: the conrputation 
record, is removed from the backup state, its associated! fteg is set'to'true ‘and ‘the result value is 
Rot copied. Only the root activation of a. computation can ‘change this flag. Clearly, this 
- Operation is outside of the purely functional programming paradigm thus far used: such resource 
managers are. to be written ‘using the guardian: apeelibintd which allows this sort of non- 
applicative behaviour to expressed in-an applicative setting. — 
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Conclusion 


This thesis has. sropeaed a. design for the. vim. computer system which guarantees the 
... Security of all online information against. loss or cormaption as a-resuit:of hardware failure. We 
.. developed backup. procedures -that are .intended-:to, execute. concurrently with normal 


. computation. These procedures record the progress of alt computation in:a:compact form.on a 


backup: storage medium.. When a computation completes, its result is.bound to:some name in 
the VIM users’ environment structure. Once this, binding is: added to the backup: environment 
image, the computation record associated. with this computation is.removed from the ‘backup 
state. We make no assumption as to the integrity ofiany:data which survives a failure except: for 
data found on the backup medium. The backup medium consists of two main devices: tape 


~" storage used’ to hold all data bound to identifiers i in the user environment, and stable storage 


which contains information in the form of computation records about all active computations in 
the system. When the recovery procedure i is ‘invoked i after a ‘failure, it first restores the VIM 
environment structure using the backup environment image. "I then begins reexecution of those 
‘commands which were executing at the time the failure “occured. ‘The time to reexecute these 
commands is greatly reduced because of the information kept: on the corresponding computation 
“records. Once all commands have been reexecuted, the recovery Process: is complete and the 
"system can accept further commands from its users. ne 


6.1 Contributions of the Thesis 


The contributions of this thesis have been two-fold. First, we developed backup and 
recovery algorithms for the VIM system. These algorithms are very different from those found in 
more convéfitional systems. The unique features of vim that required a ‘novel approach to 
providing data security lie in its applicative programming model and i in the use of a uniform 
representation for both data and programs. This homogeneity eliminated the need to maintain 
distinction between files and data, thus allowing the backup system to be more closely integrated 
with the VIM. interpreter than would otherwise be possible. The use of an applicative base 
language made it possible to have a simple organization of backup store because data i in such a 
model never changes its value. We exploited the expressive ‘power of the base language 


instructions by distributing the logic of our algorithms among the satient base language 
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instructions. The APPLY operator, responsible for creating a new function activation, was 
augmented to append to the appropriate computation record a new activation descriptor 
colresponding to the activation to be instantiated, Similar enhancements were made to the 
RETURN operator and various structure operators as well. By embedding these algorithms within 
the interpreter itself, it was possible to achieve a measure of data security far greater than what is 
possible in conventional systems. In addition, sucha design makes the operation of the backup 
_ facility completely transparent to users of the system. ‘Similarly, once the recovery procedures 
restore the system state after a failure, subsequent-computations will not be able to determine 
that a failure occurred by examining the restored state.. The’ fact’ that the base language is 
applicative also freed us from having to introduce coniplicated backup storage policies. Data 
.. once written onto to backup store is never updated; it is either garbarge colfected or bound to a 
symbolic name in the backup environment. a 


In order to rigorously specify these algorithms, we developed a formal operational model 
of system behaviour for VIM. This model views VIM as a state transition system with the VIM 
interpreter being a state transition function. We presented the definitions of some of the more 
interesting base language instructions in this model using a variant of the functional language 
VIMVAL. This basic model was later enhanced to incorporate. the backup system as well. The 
backup state was treated as a separate component of VIM. The interpreter was now treated as a 
state transition system on a two-tuple consisting of a VIM state and a backup state. Beyond being 
an important tool for expressing our algorithms, this mode! also allowed us to give a formal 
proof of correctness of our algorithms (presented in the Appendix). 


6.2 Future Research 


One important area of investigation that was not addressed i in this thesis is the issue of 
correctly preserving the state of non-determinate computations, A non- ‘determinate computation 
is one which may exhibit different behaviours for the same inputs. This type of computation 
contrasts with determinate computations for which repeatable behaviour i is guaranteed, A major 
assumption made in this thesis was that all computation was determinate. This allowed us to 
design a recovery system which can reexccute computations whose results are not recorded on 
the backup store by preserving the arguments to the computation. Such a design is possible 
because any computation in this model is guaranteed to produce the same result when presented 


with the same inputs. The basic non-determinate operator in the VIM base language is the 
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MERGE instruction. The merge operator is enabled whenever an input arrives on either of its two 
input arcs. Thus, the behaviour of this operator is characterized by the arrival order of its inputs. 
Such behaviour is inherently non-determinate. 


An important area of future research is augmenting the design proposed in this thesis to 
handle non-determinate computation. The changes made must take into consideration the fact 
that non-determinate computations cannot simply be reexecuted by the recovery system since 
there is a multiplicity of output behaviours possible. Reexecuting such a computation with the 
same inputs is, therefore, not guaranteed to produce the identical outputs. 


Most transaction systems such as airline reservations, banking, etc. are based on non- 
determinate computation. Such systems also typically have very high data security requirements. 
Enhancing the VIM backup and recovery system to support non-determinate computation would 
be an important step in understanding how highly secure transaction systems can be written in 
an applicative computer system, Issues of atomicity and indivisibility of transactions could then 
be addressed in this context. . . 


It would also be a challenging task to map the abstract specification of the algorithms given 
in Chapter 4 into an efficient implementation on the VIM system. . Realization of these 
algorithms will require optimizations not addressed in the thesis. Such optimizations include 
minimizing the amount of copying done to stable storage and efficiently reclaiming storage on 
the backup medium. These problems which were hidden in our abstract model were briefly 
addressed in Chapter 5. A truly viable implementation will need to confront these issues in 
much greater detail. . 
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Appendix A 


Proof of Correctness 


In the previous chapters, we have developed a ial model of the VIM system { to describe 
our backup and recovery algorithms. Beyond being a convenferit vehicte in’ Which to precisely 
state our algorithms, the format model can alse be‘uséd ‘tr provitiy thie- correctness of dur design. 
_ Intuitively,. demonstrating the corfectness of thé dackup itd rééovery procedures “involves 
showing that the recovery. procedures do not restore an indotrect stiite’ Baséd dni the information 
kept on backup store by ‘the backup procedurés''The cofiputitions which"execute after the 
_-Tecovery: procedures complete should not! be able to-discerti ‘thd fact-that'a failure had occurred 
before, Thus, the state of the system observed ‘by any comtpitition: instantiated ‘after recovery 
from failure must be equivalent to the observable state which @kisted prior tothe faltare. In 
VIM, computations observe the effects of other computations through the. VIM environment 
structure. It.is, therefore, necessary that the environment inmage eestortd ‘by the secovery system 
be equivalent to the environment which’ existed: before the. faire: ‘We: present a formal 
definition of environment equivalence later i in this appendix. To establish that environment 
equivalence is preserved, we examine the state transitions, .praduced,,by the system when 
interpreting the command log daring recovery and cobipate tt with the state’ ‘transitions that 
result when interpreting the same log when no backup state information i is used. To show that 
environment equivalence is preserved across the two transition seqyences, we. use the fact that no 
instruction is executed during the recovery process thatwould net alsa have been executed by 
the VIM interpreter evaluating the same command when. ne inoemation, fn the-backup state is 
utilized. Our proof is as follows: We first examine the: state. ereaiéd. by executing @ particular 
instruction in the transition sequence of the recovery process. We then demonstrate that this 
- environment is equivalent to the enviroriment-compdnent of the déate created by executing the 

“equivalent instruction under nortiial interpretation. ‘Usitig’a sitiiple indfuction atgument, we then 
--ghow that the environment: component’ of the’ final’ Mdovery state’ is” equivalent to the 
environment component that woufd have resulted iF no fiittire'' had ket sag 


In the following sections, we formally define. qur notions ‘of, ‘nmitiod sequence and 
equivalence. We then prove our main theorem: The system state after the recovery process 
completes is equivalent to the state that would have resulted Had no failure taken place. This 
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implies that it is not possible for any computation to observe the effects of a failure once the 


recovery procedures complete. 


A.1 Definitions and Terminology 


State Transition Sequences. 

Because we are considering VIM to be cdatanes system, we.can-madel the execution of 
_.. @ program as a sequences of states. The Execute function which when given a:current state and 
., enabled instruction returns the state created; by executing the instruction: . The operation of:some 
of the base language instructions are different depending upon: whether the-system is executing 
using the normal or recovery interpreter, In. our: proof,, we:shall: be concerned. with examining 
state transition sequences constructed by the respective interppeters.on the command stream 
_ preserved on the backup log. 

Definition 1: The System State is a two-tuple, < VimStaie, BackupState> where 
VimS«ne and BackupStte were defined: in: Chapter-Four’ The-recovery: command 


stream for..a system. state S is, a sequenge of romm eee 
BackupState = <Log.BHeap, BEnv> and. Logt). command = 


Definition 2: A state transition relation, K, is a rélation on states. Let S = 
<Act.H,EIS,Env> and T = <Act’,H’ EIS. .Env'>. Then, S t- Tifa (wd € EIS st 
ExecutdS,(u,/)) = T. 


‘Definition 3: A state transition sequence, <s pSp- SPs is a sequence of states 
such that SS, forl<ighl | | 


For notationat convenience, we shalt sometimes ‘denote a ‘state transition 
Sequence <S,S.,. Spas SS, 


The recovery process is divided into two phases, . In the firs, iphase, the contents of the 
backup environment are restored onto the VIM. environment.structure. Once this is done, the 
command log i is reexecuted: during this reexecution phase, backup. information is used to. avoid 
unnecessary recomputation. The state of the system after the first. phase completes is. called. the 
initial recovery state. The heap in the initial recovery state contains a structures referenced from 


~ environment entries in the backup environment image. 


Definition 4: Let S, be a VIM state such that Failure ‘S, ) = drue, Let B,. the 
backup state Soneanundite to S,. be <Lag, BHeap, BEny>. 
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Then, the initial recovery state for S, is the state: Hy {}, Env)? where 


Hu) = if 3 name st. BEny (name) = = and BHeap (uw = =¥ y then v. 
= if 3 Ruwmst. (4 u)) = RJA” 
(ROA). = wis Heap): = -Wiliensw. «4 
= undef otherwise. 


Envy = BEny 


Unlike instructions, execuied during normal, qparation,:instayctions executed during the 
recovery process use information found inthe batteupistate! Fhe: abel insttuttion, for example, 
. avoids instantiation of new activations if the, valle for b ani ct activatio j ‘ which. previously executed 
has been recorded on backup store. The commané:tog:féant! orritiie’ backup’ istate is a sequence 
ft Hiot retarded in ‘the backup environment 
structure, When a failure occurs, the recovery system reexecutes the commands found on the 
log, using backup state iiformation it has accumulated ‘about the computation, To.demonstrate 
that the recovery process interprets this information correctly, awe. examine. how the VIM 
Interpreter would execute these same commands. if. ha. backyp. sate, information is used. The 
transition sequences produced by the respective interpreters is known asa transition sequence 
pair. If the recovery system interprets the information. found onthe bbabkaxp state correctly, it 
follows iat the final states in’ ‘ite’ ‘Wwe frei sp ? aH eg must ‘Have equivaient environment 


of commands whose final results have not yet beer 


Fear Let R be the recovery command stréam for state:§ and let STS = 
55,25) be the state transition sequence aradatad duriog ‘theievaluation of the 
call: ShelKR, S;, <{},{},BEnv>). Then, S: is the initial recovery state and S,is the 
ideal recovery: State fot 'R. ENS: 18 %, te bean IDPS Ww' sited “he slandard 
transition'sequence for system tale S30 


Let R be the recovery command stream for system state ‘Ss aa let RTS = 
<R).R RP be the state transition sequence produced? @utirig the evaluation of the 
call Recoier(¢Log.BHeap.BEn). Then, Rfiei@e-thieial 1eGd very state ‘tnd R - is 

- the finab recovery statefor Ro EIS. is ‘herent BB ‘RPS is-called the’ recovery 
transition sequence for system sate ; 


Definition 6: A sequence pair for a ee state. S.'ts’a two-tuple:<R7S.STS> 
where RTS = ¢R,.Rp....RD and STS = gewwdgre ASA where, R, se are the 
final recovery state and Bie recovery sate for ave ue stream. esp. = = $1, 
the initial recovery suite for system stitte S. 
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State Equivalence 

In the following definition, we shall use the ¢ symbol, =, to denote the equivalence relation 
between corresponding state components in. different, states. Thus, if. Eny, and Env, are two 
environments in states S and S’, then Envy) = Env, iftthese two environments are equivalent. 


Definition 7: Instruction Equivalence: Let FA sl FA’be two activities. Then, 
FA(m) = FA(n) for mn €N if: 


eFA(m).opcode = FA‘(n). opcode. 

eV opnum € (opnumi Oprium2,opnums), FAC) see FAH). opnum if 
FA(m).opnum and. FA(n).opnum € Sealer. 

eV opnum € {opnum| opnum2,opnum3), FA), opnum = FA ‘(n).opnum if 
FA(m).opnum arid 'FA(n).opnum € U." 

oF A(m).opent =. FA{n).opens. 

oF A(m). Sigent = = FA(n). sigent. 

eV (dc,k, sopnum) € FAG). dest, 3 (de, l, opnurm) i in FA). pa SL FAK) = FA 0. 


Activity Equivalence: Two Activities FA and FA; ‘are equivalent if for every mé 
N, FA(m) = FAm). 


Object Equivalence: Let H, and H = two heaps defined such that Hu) = =y 
and H fu’) = vfor uu’€ U. Then, vary - 


ev = undef, v’= undef. 

ev € Scalar, then v’€.Sealar and y= y’. 

ev € Record, then v’€ Record and (i) =. ¥(i), Pepe i€Nn. 

ev € ECO, then v’€ ECO and V (u,.i € v, 3 (u,m) € v’st. (u,,d) = (u,m). 

ev € SUSP, v’€ SUSP sé if v = (u,,m) and v= (u,,n), Acku,, Mn) = 
Actu,Xit) OR H{v) € Record and v'€ SUsP and 3 state Si. where S,FS, and 
Hv} = Hi). 

eve U, then v’€ Uand H{v) = Hiv. 


Eavironment Equivalence: Let Env, and En, be two environments in states Ss; 
and S; Then, Env, and Env, are equivalent if for every nj st Env{n,) = vin, St 
Env{a))= vy where ‘f 


ev = undef, v'= undef. 

ev € Scalar, then v’€ Scalar and v = vy’. 

ev € U, then v’€ U and H{v) = H{v). H, and H, are the heap comporiens in 
states S; and S; resp. 


Containment and Completeness 
‘In order to show that environment equivalence i is preserved between States in the recovery 
transition sequence and the standard transition sequence, we will, need to examine the effect of 
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executing equivalent instructions in the two states. Thus, it is necessary that‘for every enabled 
instruction in the recovery state, there be an equivalent. instruction in the eee VIM 
. State. This property is called containment. 
Definition 8: Let <RTS, STS> be a sequence pait t for a system state, S, where R, 


is an element of RTS and S, is an element of STS, Bet ot Aad ae in S, if ¥(uyn) ¢ 
EIS, 3 (u’n) € EIS, Sb FA(n) = FA (n) nent Aas) = A. canis = FA‘, 


Definition 9: east baeece di ee etee S, and R, is an 
element of RTS and S,is an element of STS; thon-R; is manomiee if Env, = ‘Em, 
and R; is contained in i 


Computation Sets . Ne hey 
In Chapter 4, we introduced the computation treé. as an abstracti 

instantiation of function activations. ina computation, Toe tlloning three definitions formalize 

this idea 


. Definition 10: Let an activation a. al instantiated 4 aa state s os the 
computation set C of qa. ee ee 

ea EC. : 

eAny activation instantiated from an activation in the computation set C is also 


That is, . the computation: set ara activation: (ua cere te transitive closure over all 
activations in the computation tree rooted at (ua). ee 


Definition 11: A computation sequence CS for an activation instantiated in state 
S, with computation: set C-is a state transition: sequence, <$,,5;,5;,....5,> where k is 
the smallest aes mee meee See sos ageioas ii from 
activities found in C. 3 


Definition 12: A value, v € Scalar U ST, i ocoesibein nstate <ActH, EIS,Env> 
if either: 

eThere is some activity A at, — = / and hanna. = v for opnum € 
{op!.op2.op3}. and AcKu) = | 

eThere is some. activity A. st ‘A(a). = J and le opm 
{opt.op2 Op3}. Acku’) = A and Hu) = v. se 

eThere is some v’€ Record s.t. v(m) =vor v(m) = u where H(u) = vand vis 
accessible. 


u for opnum € 


ov pa BE 
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A.2 Proof of Correctness 


Lemma 1: Let R, = <Act,H,EIS,Env> be an element of RTS and S, = 
<Act, H, EIS ,Env> be an element of STS. Suppose &, be Ron an-enabied instruction, (u,i), 
where Act (us = A and FA(i).opcode * APPLY. Then, if R, ‘s ‘complete wit S, 3 a state S, St. 


S/FS, and R,,. is complete wrt Sy . - 


Proof: To prove the lemma we need to. show. that environment equivalence and 
containment holds between R,, , and some state S, for any instruction whose opcode is not 
APPLY. We prove the lemma by examining the different classes of instructions defined in our 
model and show that the lemma holds over.each of these classes. If-R as:complete wrt S, then, 
by the property of containmeat, there exists: an‘enabled instruction, a Dy € EIS, = (ud). 


1. Scalar Operations: The effect of executing a scalar operation does not alter the 
environment and so, both environments in R; oe and Si, , remain equivalent. By 
definition of instruction equivalence, we know that every Gestination {de,i,opnum) in 
FA(i).dest = some destination, (deyj.opnym) i in, FA DAES, Since. the. same scalar 
values are sent to equivalent instructions, these destinations 1 remain equivalent. 
Thus, equivalent instruetions become enabled in’; yp enes,, . Hence, ,, , is 
contained in S ie | and, so, the lemma holds ferent eonmioad 


2. Structure Operations: A structure operation performed i in state R, might cause the 
new state RK, , 712 havea different heap, Note-thag the: ; peti cobkponent does 
not change hen any structure operation ekéduted:°To see 'that the ledima still holds 
for these types of instructions, we examine the various structure operations in our 
system. : 


a. CREATE: A create instruction executed i in R, will produce a new ‘structure on 
the heap in KR, , with uid u My and size n, with all elements of the structure 
having value ‘ie of, where n is the operand to the instruction. The equivalent 
instruction in: £49, u'g) when: executedsin:5 j wittreddce a’ new structure on 
the heap in S__ , with uid w, and size a,. By our definition. of- heap equivalence, 
H,,, and is i " are still equivalent. Showing that R, +1) is still contained in 
S. ie follows the same argument. as 3 given above. | eee 


‘'b, SELECT: Amick oo cscs Geetewcasd'as 4 aewoine taumicnd at 


either a scalar or. structure: yalue,.art cafly ee ‘or llama teens 
We examine each of these in turn: 


i. value: There are two cases to be considered if the item selected from H, is 
a scalar or @ structure. 4n the fire ease. the Rein selected from: H. would 
also be a scalar or structure value. By the property of containment, the 
operands to the SELECT instruction must be equivalent Since the Pa 
and environmerit components do not : change ¢ in this, case, H, 

R,, , is still contained in S., , because alf destinations of the rere 

R are equivalent tordeatinationy i in. ‘S; and, following the argument given 

in (1). these instructians woald>-remain ‘equivalent > “Thus, R. in? is 

complete wrt Sig , in this case. 
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In the second case, the item selected in A, is‘a‘record representing a 
stream, but the corresponding item ‘in #7; is @ Suspensii.’ This case arises 
when the APPLY operator is to instantiane afuretion represented by a 
stream Ade. The stream image’Gn: Mable ‘store if restored by the 
recovery procedure.” in-state-S the: sigponsidn triggers the instantiation 
ee smrapsrnaee tes Othe “new ‘stheam’ element: Let 
Se ripe ps, be a state ‘sranaition ‘sequence Where EIS. contains all 
nabled instructions in-E/S; 7 | eabept thoes belonging to A (0 any of A’s 
sCeceidea ay; in the compu be tbted bP ‘Then: Hf, wilt contain 
the new stream element and, by the y of object squivalence, the 
two streams in H,_, anid‘, woutd Be &quivalent. Reg a8 ‘obviously stil 
contained in S_. fide, sl comple wr, 


ii. early completion: If the item selected from H, is an early completion 
structure, then the select instruction, (ud. is added onto the queue, Since 
~ operand: values’ are ‘equivalent: (because Gf <bntaitiment), the SELECT 
operation perforned in. 5, sould. slecraniect emeariy completion structure 


from H, The SELECT instructions sreomogne get added to. the 

ec-quede: Sine no new isis bose e enab led, ogee: 

in S Wet 
eT 


dif, suspensian: If the item aes eine e nsion, the. instruction 
~"yefereticed “in ‘the’ suspension is i... BY: Qut,wproperty, of 
containment, the item selected in S, must also be a suspension and the 

. instryctian -referenced..in-shis saspaneiqn. woukd:ale be signalled. The 
equivalent instrpstion would getsigneliodda bath -d}-end:if,and, thus, - 

__ instruction ..equivaleage: is stil: preserved.) dae, execution of the - 
suspension: operant changes the Gridntn ee ees conspleiien queue in’ - 

h, states. , the: SEL BGT: jnstrustions: Since: the two SELBCT - 


G. SET: By piety Sy iia’ the value ee ae equivalent 10 : 
nites ipa ill “Th ‘addition, os ! 2 HE 


3. T crminate Operation: Execution of hig TERMINATE instruction causes’ eoritiot to 
retumn to the shell. with the <name. vive binding added 1 The User Environment. 
‘Since Ris: ebntained nS ste “opieriet 28! uneOteehale slileit Me be 
equivalent} in both R, and Ss; Env, ,_, is. therefore, equivantae2ny) 7 ee ue ay 

.. the same argyment given, jin () and we see that, Ri is iY enptaingg 5 $l: 


4, Return: Operation: The RETURN instruction, fakes tito. argements, she rctum : value Z 


1 2 a RNR Pe Sng et Ne eS edipiglt thet en ud caw Seria en ety 


and the target list. By the property of containiment the retum value and target list in’ 


the equivalent instructions in R. jand S, ns be Plena R,,, 8 contained in 
|S, Since the turger nddresses of the or iid’ ‘sgutidlent anid ihe’ result 
values are equivalent in the two states, 


18 PROOF OF CORRECTNESS §A.2 


5. Tailapply Operation: The TAILAPPLY instruction. takes in three arguments, the 
function closure, argument list and return link. By the property of containment, all 
three operands must be equivalent in the executing instructions in corresponding 
States. The result of executing-the instruction is to:add a new.activation and to signal 
instructions in its own activation. Because the:closures and argument lists are 
equivalent, the instructions enabled in the new activation must also:be equivalent in 

R,,, and S, 1: Following the argument given:in<(1), it is easily seen that R,_ , is 

contained in S.A similar. argument can. be eppiied in the analysis of t the 

streamtail operator and.isomitted.here. = 


Since we have shown that the lemma holds for all instruction classes (excluding APPLY), 
the lemma is proved. 0 


The effect of executing a function is visible only in the result value returned by that 
function. Thus, given a computation sequence for some: activation, the values that are still 
accessible after all activations in the computation sequence have completed are precisely those 


returned by that activation to its caller. 

Lemma 2: Let <S,S,,...,5,> be a computation sequence for an activation A. Then, the 
values accessible in S, "Gok he not in S dre those Values accessible, from. te instructions found in 
the destination list of the activation, A. 


Proof: (by contradiction). Suppose there is some vatue, y, that is accessible in Sy , but not 
in S and is also not accessible from: thé retum link to the activation. ‘This'value must have been 
created by some instruction that‘is'an element of sonve activation’ inthe computation set of A. 
Let this activation be a. In order for-this sthictuse td bé accessible after the termination of this 
activation, it must be returned ‘as a-result of tvat activation -sincé “any teferences to it from 
instructions within. a are lost once the RELEASE instruction ‘Exeeutés: ‘Let its caller be 8. In order 
for the value to be accessible in S, it must,-by the stime redsOrritiyad above, be returned as a 
result of this activation as well. Continuing | this argument, we see. thatthe value can only be 
accessible in S, | , if it ts retutned as the result of A. . But this conta O our Levin hypothesis 
and so the temma is proved. o 


Theorem 1!: Let <RTS.STS> be a sequence pair for a System, state Sand let R, € RTS and 
S.€ STS. Then, if RR, R,, and R; panies WS, then 3a state S; St S PS, and Ry 
is complete. wrt Sy 


a 


- Proof: Our proof is by induction. The induction sep shows that the theorem holds over all 
instruction. classes for our System. 


Basis: Let RTS = = <R Rp and STS = <§ (Sp. Since R, = S;. and by definition of the 
initial recovery state, E/S) =p, R; = Rand, 5, om ee Thas Ry te dened the theorem is 
satisfied. 


Llypothesis: Suppose that the theorem holds for all sequence. pairs <RTS. s T. > ‘nek RTS 
is of upto length & i> 2. 


§A.2 


PROOF OF CORRECTNESS 


Step: We show that the theorem holds for a sequence belt <RTS, STS> where RIS} is of 


length (+1. 


Non-Apply Instruction: Refer to Lemma 1, 


Apply. Instruction: There are four types. of: activation descriptors thet a are found ona 
computation. record: These descriptors can either be. of type: apply, value, tailapply or 
streamtail, When an APPLY. instruction executes :in Rye ‘examines the’ activation descriptor for 


the activation to be initiated. 


1; 


apply or nonexistent Ade: If no Ade exists, then state. Rie +; 8 complete wrt state 
S,,, Since the APPLY instruction executing in. state. Ry ySes-20. backup information. 
Since R. ;is complete wrt S$ and equivalent instructions execute.in these two states, 
by analysis similar to the one given for the TAILSPPLY, operator in Lemma 1, 

+, and S ed remain equivalent. This. same. _analysis. holds when the APPLY 
otitaee is to instantiate, an activation which. has. an. activation. descriptor entry of 
type apply. Since t no result i is found in the, Ade, anew. activation. is created by the 
APPLY. 


2. value: If a value Ade exists for this activation, then R,, , differs from R, in that tthe 


tn 


value v is accessible from an activity in R,,) ’ but is not gecessible from this same 
activity in R, The equivalent instru ‘executing “S, would cause the 
instantiation of an activation, (uA), because no backup information is used, By 
Lemma 2, there is.a state transition sequence CSS, juin, such: that the values 
accessible in S,,, but not accessible. in. Sp "are those. values. accessible from _ 
instructions found in the destination list passed to the activity, A. These values 
represent the result of the activation and thus must be equivaient # the values found 
in the Ade of the activation used in R, (since, we have no non-deterministic 
computation). Since thé apply instruction: execu 
activation found on the’ Ade to-all destindtions; and vy the’ pt 'y Of containment, " 
the two APPLY instructions executing’ itt R, “aid “S' have egilivalént destination © 
instructions, state R |, mtist be’ contained if state ene “tre ‘environment — 
image does not ‘charge in either sate ried ha 1 aid, $0, the 
theoretri holds for thiis'case. . 


: tailapply: If the Ade for an activation has type TAILARPLY, ‘thee: Ri, F difters from 


_ R, in that R,, , Will contain a new activity. A. whose argument-record is retrieved . 


from the activation descriptor. When the corresponding APPLY instruction executes 
in 5S, it will cause a new activity, A‘, to be created whose argument record is not 
necessarily Gas same as in A. Consider the state transition sequence, 
<S S54, m Where S,. pF Si, mona TAILAPPLY instruction which creates a 
new peilvity, “ip such that he A, There must be such a transition sequence since all 
computation in the system is determinate. 8 is a descendent in the computation tree 
rooted at A~ Fix the transition sequence from S,toS., so that E/S.| contains no 
instruction from any activation on the path from A‘to "B (or descendents of any such 
activations) in the computation tree rooted at 4°. This is clearly possible because of 
the non-determinacy of the Choice function. The only new values accessibic in S, 

not accessible in S ire those referenced from B. Since B= ALR i+ 8 still contained 


ein R, Strids the ‘value of the 


cha DONATO 0 Say a gic aie hang hope ening. Tee NEE Esa BE a I eR eS RS SERRE ee TT ERTS Sree Cee 
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in Sit . Since the environment image is not updated in.either transition sequence, 


environment equivalence is still preserved. Thus, R,, , remains complete wrt Sit at 


4. Streamtail: The case when the Ade is of type. cee is very similar to the 
TAILAPPLY Ade given above. In this instance, R inf differs from R, in two ways. 
First, the stream image on stable store is:restored onte H, -'§ecoridly, a skefeton 
activation is created to instantiate production of the’ venedirtdes Of thesréam, In state 

S, the apply operator will cause a new activation, 4; to beictéated to produce the first 

x iit of the stream. To ae the property of contdiviinént, we ‘consider the 
transition sequence, <S p Sint > where EIS contains no instruction from 
any from A (or any of {ts faa in the computation (Yee Yooted at A. At this 
point, the first stream element is completely ‘defitied atid’ there is a Suspension in A 
which is not yet enabled tb produce ‘the mth “By < out definition of object 
equivalence, the corresponding Streams i in S mand R, ? ate ‘equivalent. Thus, all 
destination instructions of the APPLY in we’ Tes ng states which on 
enabled also remain equivalent. Hence containment sefit Holds between Si, 


R,,, Since the environment image does not change,’ Ri, 1 réthiaing: ‘combi wi = 
S 


ltm 
Since we have shown the theorem for. each of the classes of Ades which may be found on a 
computation record, the theorem i is ‘proved. 0g 


Corollary: If <RTS,STS> is a sequence pai, the mR, fs copie wrt S, where R,and S, 
are the final states for RFS and STS respectively. ae, 7 


Proof: (by contradiction) 


Suppose that R,.was net complete wrtto Sy Since. EIS, =. Pe we know that.R,is contained 
in Sy It must, therefore, be. the. case, that environment equivalence is not preserve ‘between the 


two states,, By Theorem. 1, we know:that & Musy.-be, complete wat some state S where S, FS, 
As a consequence. of the hypothesis, thiete must, be, copie envingnaent altering instruction 
executed in the transition sequence, <S,S 4 peSp that iainat exccuttadin, R7'S-0f,vise versa. This 
is a contradiction since by phe ih 571 Same command stggm x used ani produciag both the 
ideal recovery state and final recovery state. Thus, our ir hypothesis that R R ts 0 not complete wrt S; 
must be: seven eandnctann dade etee oO FeO ee" 
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